Measuring start-up time for .NET, Java, C++

A comment here points me to this comparison by Decebal Mihailescu of start-up times for processes on Windows using different runtimes: .NET in several versions, Java 1.6, Mono 2.6.4, and Visual C++ 2010 (native code).

image

It is notable that native code is much faster than the runtimes, and that .NET is ahead of Java – to be expected, perhaps, since Windows is its native environment.

The test application is tiny and when we are talking about a time of less than a tenth of a second, users are unlikely to care much. I would like to see tests based on a larger application; on the other hand it becomes increasingly difficult to make a fair comparison.

It’s a shame Embarcadero Delphi was not included, though I’d expect similar figures to those for Visual C++.

Start-up time is critical to perceived performance. One reason I use an ancient version of Paint Shop Pro for simple image manipulation is that I can double-click an image and be editing it instantly, whereas alternatives like Adobe PhotoShop or the free paint.net make me wait. Unless I need the extra features these provide, I stick with fast and simple.

VN:F [1.9.18_1163]
Rate this post
Rating: 10.0/10 (1 vote cast)
Measuring start-up time for .NET, Java, C++, 10.0 out of 10 based on 1 rating

Related posts:

  1. Oxygene for Java released: develop for Android and Java runtime with Delphi language in Visual Studio
  2. Microsoft’s Azure toolkit for Apple iOS and Android is a start, but nothing like enough
  3. Tech-Ed: Don’t start new projects in Delphi or FoxPro
  4. Java versus C/C++ performance – which is really faster?
  5. Lenovo’s bundled Start menu: more OEM trouble for Microsoft

5 comments to Measuring start-up time for .NET, Java, C++

  • Chris

    The actual test seems a bit artificial to me since it concerns dummy applications without a GUI. Perhaps a better test would be to compare the start up times of (say) an application with a single form that has 20 ‘standard’ edit controls across C++/MFC, Delphi/VCL, C#/WinForms, C#/WPF, etc.

  • No but it does show without UI elements, and all the supposed improvements in JVM/JIT that advocates claim, java is, and always has been slow!

    Add in the dreadfully performing swing or awt and watch the java app fall to its knees.

  • Chris

    @gary: my underlying point was, the particular UI framework (or even control set) used is frequently very important – e.g., I find WinForms a drag on low spec machines compared to the VCL (= Delphi’s native UI framework), even on Vista when VCL apps hypothically shouldn’t have the benefit of classic GDI hardware acceleration. My hunch is to put this down to the inherent slowness of GDI+, which WinForms use, yet GDI+ itself is native code.

  • @chris, with you all the way, I’m a delphi dev since ’95 (dont use it much these days) so I have always preferred compiled compact exe’s for blistering performance. An actual better real world test would be interfacing to a DB, thats what most development in the real world requires.

  • john

    @Chris
    may be it was the time of your writing, but it seems that a UI benchmark was included too.
    Check again http://www.codeproject.com/KB/dotnet/RuntimePerformance.aspx