I had a quick look at the .NET Native Preview. I am interested to see what the benefits might be. Note that currently the preview only supports 64-bit Windows Store apps.
Here is what is promised:
For users of your apps, .NET Native offers these advantages:
- Fast execution times
- Consistently speedy startup times
- Low deployment and update costs
- Optimized app memory usage
I created a small C# app that counts prime numbers using a simple approach. I created it first as a Universal App that does not use .NET Native, and then as a second app that does use .NET Native.
My initial results are disappointing. The time taken to count prime numbers is similar in both apps.
As a further test, I added code that adds the prime numbers found to a ListView control using an async task. The idea was to see if GUI interaction and multi-threading would be more revealing than simply crunching numbers in a tight loop. The apps takes much longer with this enabled, but again, there is nothing to choose between the two.
Did I really succeed in compiling the app to native code? I think so. Here are the contents of the AppX folder for the standard .NET executable:
and here for the native compiled executable – note the additional DLLs:
I am not actually surprised that there is no performance benefit in my example. JIT (just-in-time) compilation means that any .NET application is native code at runtime, though optimization might be different.
I have ended up with a much larger app to deploy, though the relative difference would be less, I imagine, with an app that contains more code.
I can also readily believe that start-up time will be better for a native compiled app, since there is no need for the JIT compiler. However my app is so small that this is not significant.
My question though is what kind of app will benefit most from native compilation? I would be interested to see guidance on this.
Of course it is also possible that later iterations of the technology will yield different results.
Why isn’t .NET apps NGEN compiled when installed on a host?
via – FAQ – http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx – apps will get deployed on end-user devices as fully self-contained natively compiled code (when .NET Native enters production), and will not have a dependency on the .NET Framework on the target device/machine
A good question is, will a runtime engine (not the net. but an other one) be necessary here? MS C++ application requires the c++ runtime engine. If it is the case, then for me it may be “native code compilation in MS sense” but with not benefit at all for the end user. I will rather just look at other development tools which are also more portable to other platforms and really native. On other hand it is good from Microsoft to acknowledge that the net. framework is for some applications/hardwares really too big and too slow. On the other hand it is also true that it would be difficult to develop large applications (and usefull application) with Script languages. C# is maybe here a better solution. Any way, my feeling is that MS is offering development tools for lightweight unusefull applications that feature code obfuscation (javascript/axml) and nice but heavyweight language C# that produce application that does not run so well on Windows PC like netbook/tablet.
One of the benefits, quite significant, is that you don’t waste battery compiling each time you start the app. On a small prime app I would have questioned the jit if it wasn’t as fast.
Take a larger app as maybe power point / word and you will notice a large difference in startup times.
Also I don’t understand what you are talking about Alexander, you make little sense. Gcc relies on its “runtime” too, the c++ dlls aren’t really a runtime per say. On any windows device you won’t pay the price of the size of any runtime, quite the opposite, the apps get smaller because you have .Net to do alot of the heavy lifting.
To compile .Net to native code with built in runtime will however open some doors for Microsoft in the cross platform environment, much like mono does.