I was thinking about it. I have a program written in delphi which uses up 720kb of ram. My .Net rewrite of it uses 20megs of ram. Ill chalk up half of that to my not being memory concious and trying to get it working before fine tuning it.
My program starts up as 10mb of ram, then jumps to 20, but doesnt really get much higher.... maybe a meg or two.
But I also chalk some of that up to the .Net framework having to JIT compile it, then in order to keep it compiled, it hangs out in ram.
Why so much memory for such a tiny application?
My thought is that .Net isnt a native process to XP/2000/ME/98. Its running another application (the framework/JIT compiler) just to run whatever it is youre running. Plus the framework does something about managing its own memory, which is something else running.
Well on these machines, its an extra service to run.
On Longhorn, thats going to be the native service all the time. The .Net memory manager would always be running, as would the JIT and other .Net features.
I think theyd be optimized because, on Longhorn at least, they wouldnt be acting as an interpreter to another OS (XP, 98, etc). Theyd be the native process.
Id think .Net apps would take up less memory in that case because its just the memory associated with the App, not the framework (thats already covered by system resources).
Also they should run faster, while the older apps that use the old APIs would be running piggyback on the OS instead of being built in, and running slower.
This should make .Net apps run faster, while older/other apps run slower (might not notice with those blazing fast CPU speeds) and take up more memory.
I think this would cause a higher demand for .Net apps as well. Now its a hassle to install the framework. Yes, I had VPs complain about it because they bought .Net instead of VB6 (which I had asked for at the time) and had to install 20mb packages on 200 machines to run my 200kb programs!!
Or the world could give MS the middle finger at, yet again, messing with their computing experience in the name of progress.
My program starts up as 10mb of ram, then jumps to 20, but doesnt really get much higher.... maybe a meg or two.
But I also chalk some of that up to the .Net framework having to JIT compile it, then in order to keep it compiled, it hangs out in ram.
Why so much memory for such a tiny application?
My thought is that .Net isnt a native process to XP/2000/ME/98. Its running another application (the framework/JIT compiler) just to run whatever it is youre running. Plus the framework does something about managing its own memory, which is something else running.
Well on these machines, its an extra service to run.
On Longhorn, thats going to be the native service all the time. The .Net memory manager would always be running, as would the JIT and other .Net features.
I think theyd be optimized because, on Longhorn at least, they wouldnt be acting as an interpreter to another OS (XP, 98, etc). Theyd be the native process.
Id think .Net apps would take up less memory in that case because its just the memory associated with the App, not the framework (thats already covered by system resources).
Also they should run faster, while the older apps that use the old APIs would be running piggyback on the OS instead of being built in, and running slower.
This should make .Net apps run faster, while older/other apps run slower (might not notice with those blazing fast CPU speeds) and take up more memory.
I think this would cause a higher demand for .Net apps as well. Now its a hassle to install the framework. Yes, I had VPs complain about it because they bought .Net instead of VB6 (which I had asked for at the time) and had to install 20mb packages on 200 machines to run my 200kb programs!!
Or the world could give MS the middle finger at, yet again, messing with their computing experience in the name of progress.
