Native applications

I was just reading on a blog a reference to an article Michael Swindell published about native application development. It's fair to say that you don't always have to agree with everything someone writes, but I think in this particular case, there is misleading information.

The story of the .NET framework lagging behind native performance just doesn't cut it anymore. Wake up and smell the coffee. We are three versions into the .NET framework and Microsoft is already talking about 4.0. While we are seeing new things that will make applications and architectures more flexible and easier to maintain (such as dynamic binding), Delphi developers are still complaining about the garbage collector.

This might come as a shock to you, but in a business application, your end customer is not going to know how long it took him to destroy that order object, or to create it for that matter. He cares about his application. He cares about interoperability. He cares about his ROI. With all that the .NET Framework (or Java for that matter) has to offer in terms of productivity to the programmer, with all the frameworks that exists to make application development easier to maintain, the native vs interpreted performance argument doesn't stand anymore.

I'm not saying that native is bad, far from it. Right now, and for the foreseeable future, there is a place for native code, just as the article points out, something needs to be under that virtual machine or the RIA. Until all computer systems (excluding my mother, she's already on .NET 3.5) have the .NET framework installed, there will be room for small utilities to run natively. But enterprise level or businesses do not have an issue with making use of applications that use the .NET framework. They don't have an issue with deployment. You can still automate and accomplish easy deployment with .NET (and I'm not even talking about ClickOnce).

Every day we have faster processors coming out, we have cheaper memory and yet 6 years after the release of .NET we are still clinging on how native out-performs managed. They say you shouldn't dismiss something without having really tried it. Unfortunately that's something I see a lot in the Delphi community.




19 thoughts on “Native applications

  1. Bruce McGee

    The only thing that will resolve this one way or the other is some kind of comprehensive and up to date benchmark comparison.

  2. QbProg

    When people complain about performance of the .NET framework it isn’t about "which string performs faster" or else. It is about the 150mb redist, the terrific startup times for moderatedly large applications, the GUI performance (i.e. WPF), etc… I really appreciate the completeness of such a framework, but it’s not the best target for non -enterprise applications. Plus, after three versions it is not clear what tecnology one should choose between the many toolkits. It is a mess with old COM components, windows forms, and WFP interop. VCL is one from 10 years now, it has it’s own limits, you can’t do the many things you can do with the .NET framework, but for DESKTOP applications is the one I choose.In delphi (or any other native toolkit), I can build a "standalone" application without any worry.

    I don’t complain about garbage collection, I do not like it. I use automatic memory management in C++ in many other efficient ways, and from Delphi 2009 I will do that even with pascal.

    BTW, I appreciate really much the .NET framework, but it is a metter of choice for every scenario you need to face. I appreciate it really, except for the "desktop/GUI" part. It is terrific. And IHMO, in the last years, it is better not to make long term investments in Microsoft Tecnology 🙂 It is going to change !

  3. Hadi Hariri


    Care to elaborate?


    I think you’re missing the point of the post. And if there’s meant to be any benchmarking, it should be of SQL Server vs Oracle vs Firebird vs MySql. Your database and the network is very the true latency is.


    Appreciate your feedback. Some points:

    1. Which redist of 150MB are you talking about?

    2. The startup time has been greatly reduced, but irrelevant of that, how many times do your customers open and close a business application? Again, opening a database connection can take often longer and that is sometimes more frequent.

    Regarding which technology to use applies to a lot of product lines and companies, but it’s beside the point of discussion.

  4. EL Cy

    Long term, is quite obvious that the VMs will prevail (JVM, CLR, DLR, MLVM…etc) … but, practically speaking let’s see what’s the current status of the VM’s on the desktop NOW:

    Just get some notices based on my experience with some apps:

    – all the major IDE (Eclipse, IDEA, Netbean) are 100% Java and are very snappy !
    – I have to agree that JDeveloper on the other hand is a hog 🙂
    – last JRE 1.6_10 RC2 is 14.7 MB
    – Java is really multi-platfrom, and OS

    – YM! for Vista (using WPF) took over 200MB without even starting to chat !
    – If .NET is such a good performer on client (the server hide the perf due to the network+various tiers) why there are no major apps written in .NET (except Paint.NET) ?
    – MS Office suite is pure VC++ and are very snappy (MS don’t eat his own food I’m afraid … just compare this situation to Java and Delphi)
    – VS is VC++ and are very snappy, with some .NET hosting for designers & co.
    – last .NET 3.5 SP1 is 231 MB (due to the packaging, the new client profile will help)
    – .NET is MS proprietary (with some ISO standardization) and is pseudo-multi-platfrom (where the platform is Windows) and don’t mention Mono or Rotor (that has some licensing issues, ex. WinForms) to make .NET a real portable client framework.

    I’m not saying that Java is better on the client (both are great on servers) … but where are those great .NET CLIENT applications (Paint.NET not to be considered) ?

    The investing is happening on both fronts, so there will be no winner here… just long term, the winner will be the "virtualization", including virtual machines that will provide a rich platform that can host applications written in various programming languages. In the meantime (until these VMs will be available in 100% of the PCs) and once the performance issues will be solved (hardware CPU + RAM is cheaper & cheaper) we have to count on the snappy native application that run directly on the CPU bare metal (without any intermediate layer) and are self contained (even if 20 MB like Skype, that’s a Delphi app)

  5. Hadi Hariri

    @EL Cy

    Boy did I NOT want to turn this into a .NET vs Delphi flame war, and I’m not going to. My point for initially posting this entry was that the IMHO, the article doesn’t reflect on the reality of things. At no point did I criticize Delphi or even mention it. I was talking about NATIVE. Unless you’ve forgotten, Visual C++ is native and Microsoft are still actively developing it.

  6. EL Cy

    Don’t wanted to hurt any feelings and start any flame here :(…

    Just pointed to some facts (that can be debated if I was wrong). I’m not a programming bigot at all and I can understand at a level some extreme positions … BUT in the meantime I really enjoyed working in all of these areas (native + VMs) when fits and try to better express my creativity using the tools at hands instead of trying to write everything in assembler just because the code will be absolutely "faster" and I’ll look "like a hacker" 🙂

    Real programmers should use real tools & languages that make them productive (ex: RAD)… and as we see now the tools evolved faster then the programmers, so we should keep the eyes opened and adapt ! The childish argument of "my tool is better that your tool" will simply make no sense in the eye of a customer that will pick the best end-result anyway (or maybe not :)… depending on the customer)

  7. Marshall Fryman

    The latest versions of .NET can cause problems with other enterprise software (thinking Citrix here). Also, notes in <a href="">support articles</a> like

    [quote]Note: Applications using the .NET Framework 3.x Windows Presentation Foundation (WPF) graphical libraries might cause performance degradations.[/quote]

    don’t particularly inspire confidence. I also find it interesting the MS doesn’t drink their own kool-aid; however, the underlying concepts of .NET are good.


  8. Bruce McGee


    If some code runs noticeably slower, it doesn’t do any good to say that the "real" bottleneck will wind up being something else (database, network, etc).

    For instance, my favourite nit pick about .Net client applications is how sluggish WinForms is in non-trivial UIs.

    I’m being completely open minded when I ask about real benchmarks. I’m open to the idea that .Net code will outperform native. I just want to see the numbers before committing one way or the other.

  9. Bruce McGee

    Just another point about deployment. Not all organizations are easy going about installing the .Net framework on their machines. Partivularly their servers. We even had trouble getting one company to upgrade their servers from .Net 1.1 to .Net 2.0.

  10. Dave H

    Well, I gotta jump into this one: I really wanted to like Dot Net – really. C# has many similarities to Delphi (as it should, sharing the same designer) and it’s certainly a lot quicker to develop in than MSVC++.

    But …

    The runtime overhead is just too much, both in size and speed. I’m currently working in consumer electronics, and my code has to ship on the memory in the devices – no way we could ship the runtime with the project and have still leave room for our customers data. And there is a noticeable difference in speed between a native app and Dot Net.

    I did a side project for a friend that massaged stuff out of an Access database and into an SQL server setup – took the time to do it in C++ Builder and C#. The Builder app could complete a run before the Dot Net program got through the first few thousand records – it was a literal difference of hours. Same database server (MS SQL) on the backend in both cases.

    Maybe it’s just me, maybe it’s the way the C# was structured, but I think it has more to do with the whole framework being overwritten and bloated. In any event, I shan’t mess with it again for the foreseeable future.

    Just my 2 cents –

    Be well,
    Dave H.

  11. Hadi Hariri

    @El Cy,

    I’ve always defended that you should use the best tool for the job.


    I’ve said in the past and continue to say so: WinForms sucks. But Enterprise level apps aren’t all about UI’s either.


    Embedded is one area where native can be justified. Note I didn’t say native is bad. Again, my point was that Enterprises don’t only use or only want native as the article seems to point out.

  12. DelphiFreak

    Ok, just an example.

    If you can win this little competition with a .NET app then you have convinced me 😉
    Of course it must run on win and linux.

    Have fun!

  13. Hadi Hariri


    Clearly we are on a different wave length here. Maybe you should read my post and the follow-up comments again.

  14. Yogi Yang

    I have to say that Native Code is there to stay.

    After a few experience with .NET based business applications like Safal ERP, Microsoft Small Business Accounting I think .NET is not a good choice to use for any kind of descent application. Also consider the case of now famous Painter.NET its performance is pathetic at best with moderately large files.

    Yes small utilities in .NET run at acceptable speed but for them to run well one will have to upgrade to high end hardware which is generally not possible in enterprises having 200+ PCs.

  15. Leonardo M. Ramé

    Hadi, you mentioned that .NET has better frameworks, and that is one of its advantages over native code. That **could** be true if you are talking about Web based apps, it’s a fact that Delphi is way behind ASP.NET and Java in this aspect. But when it comes to desktop applications, nothing beats Delphi and the great third party component libraries around it, both, in simplicity of development and speed of execution.

  16. ib


    Part of the reason why we differ in opinion is because we work in a different industrial/office environment.

    Our ROI is improved if we do not introduce new elements in the operating system. At this time we purchase Vista machines
    and down-convert to XP so we can better maintain factory with known, tested and available drivers., no relearning and
    retraining involved. We had to compare the benefits of the new features with the operating system.

    We also compared the Benefits of .NET verses Native applications. All our currect executables will not benefit from
    the .NET framework. It only helps the developers and network administrators. We also do not like the tight coupling of
    the .NET with the network admin. "One has to be influencial in both camps to make .NET successful in our enterprise".
    So dynamic binding although great as a concept is difficult to implement logistically.

    We simply cannot deploy .NET on 3500+ machines many which are old but productive ( Excellent ROI )., our initial test
    with deploying .NET to close to 100+ machines that primarily do MS Office applications went OK but the next 100+ that
    did specialized applications did not work well at all and we discarded .NET for now. As you point out., we may look at
    it with newer infrastructure.

    The 80-20 rule applies here. Delphi developers are concentrating on the 20% that affect all programming routines such
    as the "garbage collector", the new features in .NET , if really useful I predict will find their equivalent into Delphi VCL
    soon., and without the overhead, security requirements and dependencies imposed by .NET


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s