I’m an admirer of Times Reader; in fact I’ve become something of an addict. Then a discussion about .NET performance prompted me to check the memory usage:
At 92MB working set and 50MB private working set, this application uses an alarming amount of memory. I found this interesting as it’s an example of a real-world Windows Presentation Foundation application. WPF is great to work with, but if it catches on, how many concurrent WPF apps will we be able to run before our shiny Vista systems choke?
Caveats: All three of Vista, WPF and Times Reader are in beta, so things could improve; then again all three are close to release, so this is a real concern. More research is needed.
Of course it’s possible that Times Reader is just holding far too much data in RAM, though it is such a great app in other respects that it is hard to believe.
Other points of interest: as you can see from the screenshot I have Paint.Net running as well as another .NET app, Guidance Explorer, both of which consume less than half the amount of memory. In fact, Paint.Net’s usage is not bad in this context, given its sophistication and the fact that image apps tend to be memory-hungry.
I’ll have another look when the full releases are available.
I investigated how much overhead WPF is introducing by comparing two trivial to-do list apps of identical functionality. One is XAML/VB.NET; the other is Windows Forms. Both compiled to release builds in VS 2005. Here are the results:
Working set: 30MB
Private working set: 11MB
Commit size: 44.5 MB
Working set: 13.5MB
Private working set: 3MB
Commit size: 15MB
So on the face of it, there is a substantial memory jump for WPF.