Ed Voas stated this on Konfabulator's forum on Nov 9th...
(He is one of the lead developers of the Windows Version of Konfabulator)
I just wanted to see what Frogboy or others have to say. This sounds like it makes sense. I am a Konfabulator AND Desktop X User (yes, I am a paying registered user, not just a free user that hasn't "helped" the cause for both groups."
"In fact, we are right in line with Desktop X. I verified this this AM. For example, I looked at the Desktop X digital clock widget, and it's private memory was 4MB. A more complex K widget, The Weather, took about 4.5MB of private memory. Private memory is the memory actually allocated by the process. The number you see in Task Manager is the amount of total memory used in RAM, but this is not memory that is necessarily used. This memory includes shared libraries, etc. that are linked and loaded on app launch. Typically, this amount of space is not stuff that's actually used more than once (bringup) if at all. When the OS needs more memory, it will page this memory out and reduce the working set of the application to just what's needed. But if you have a bunch of free RAM, it won't get paged. But you don't NEED it to get paged.
So for example, that same Desktop X widget showed me:
4MB private memory
2MB working set (this is what you'll see in Task Manager)
10MB max working set
Note that last number. Considering our smaller widgets take around that or less (larger ones take more - and the more images, then certainly that's more ram), you'll note that we are not that far off. The Weather showed:
4.5M private
12 MB working
12 MB max
The difference here is that we aren't calling anything to force us to page out. When I do that, I get:
4.5 MB private
2 MB working
12 MB max
You'll note that our working set looks about the same as desktop X. If i call this API to page ourselves out every minute, I can get our working set to about 400K, but at that point, you have to page your application in every time something interesting happens. Plus if you keep paging out, you'll keep the disk access hot, potentially stopping a portable's hard disk from spinning down. So clearly that's not desired. So what I did last night was try an approach to flush ourselves to disk after we load a widget, and I don't call it again. This allows the widget to keep what it truly needs to run resident and removes the cruft from RAM.
What I am saying is true in any paged VM system. Mac OS has the same deal. If you look in top on the Mac, you'll see that some apps seem to take up ungodly amounts of memory, but a lot of this ends up being shared memory, or memory that can be paged out, RPRIV in top is the only number that really matters... it's the amount of RAM the app actually allocated. As mentioned, that number on the PC is currently around 4-5MB. And as mentioned, that number is the same as Desktop X.
In short, my point is that Task Manager shows you typically everything the process needed to run unless you got so low on ram that it needed to page the application out. On my system, that number is 12M because I have 1.25G of RAM. If you have less RAM, I'd bet that number might be lower because its paged some of the app out. And like I said, we really (from empirical evidence) only need to keep around 2-3M in RAM max to keep the app responsive and not hitting the disk. I've already made that change so that people can feel better about what they see in Task Manager, but it's just an accounting illusion. But if it makes people feel better, so be it."