Memory management in NET is non-intuitive.
NET doesn't free memory immediately (for speed) so the memory usage appears to bloat very quickly. If memory is in short supply, NET will free it's unused memory. If memory is not in short supply, NET will appear to chew through it at a rapid rate, as it
allocates new memory without fully clearing freed memory.
The point is that it doesn't matter if NET uses memory that's not needed elsewhere; it would only sit there unused.
We had exactly this issue with a customer who complained that our .NET windows services showed ever-increasing memory consumption. They were running on dedicated servers, so there was no competition for the memory.
As an aside: If there are multiple .NET applications running on the same machine, does the framework share the memory allocations between them? Does this make for more efficient memory usage when there are multiple NET apps?
As a developer, NET is attractive as it's easly to move to from unmanaged C++.
Most development I have done in my career is similar -- database driven business applications -- and I have never needed to use calls to the windows API more that twice in 4 years. imekon is writing fairly minority appications (there aren't as many apps
that use MIDI compared to database apps) so I would say that for Delphi to support the MIDI API is lucky; most frameworks would have not bothered for pragmatic, business reasons.
Yes, Delphi is productive, but Pascal is still a minority language and business will not want to pay the cost of re-training it's developers. For example its been 12 years since I used Pascal -- I could probably read it, but developing it would be painful
without training. Moving to C# took about two weeks (including the basics of the framework library).
The whole framework download issue will go away over time as it is now included in the OS install. This is exactly what happened with VB runtime DLLs.
My 2p worth.