The default memory value column shown in Windows Task Manager is the amount of ram the process has allocated in physical memory only. Reading this value alone can be quite misleading. For example right now I have three instances of Visual Studio open (for multiple branches of PCSX2). One is using 180 megs in the coveted first column of Task manager. The other two are currently using about 42 and 35, respectively. If I click on one of the other MSVC instances that I haven't used in the last hour or so, its use will jump to about 80-100 megs almost immediately, and then will continue to increase as I do stuff in that window. Meanwhile the one I just minimized will drop back down to 80, then 60, then 50, etc. Magical!? Not really. It's being flushed to the windows swapfile and replaced (typically) with disk cache contents rather than other programs.
More importantly, when I click on that program it initiates quite a bit of swapping to bring that app into memory so that it can be used.
Secondly, CCC is a .NET Framework app, and so its memory allocation values are going to vary from operating system to operating system, due to differences in how .NET allocates ram and how that registers in Task Manager. For example, currently .NET defaults to allocating a flat 32 megs of contiguous ram
per .NET process, regardless of if the app is solving the riddles of the universe or just printing Hello World. And then it grows that contiguous allocation as needed in 32M chunks. But it gets more complicated since that special Framework Heap is managed by the .NET Garbage Collector and not the Windows Heap Manager, so it shows up somewhere else entirely from the program it technically belongs to (in fact it doesn't show up at all in the Task Manager because it uses a special low level method of memory reservation). All you see by default in Task Manager is the memory allocated and managed using traditional Windows Heap services (which would be, in the case of a .NET app like CCC, .NET Platform invocation of C++ code or legacy GDI objects, among other things). .NET Framework overhead is "missing."
Thirdly, as I mentioned above,
most disk swapping is in fact caused by the disk cache --
not the heap allocations of other programs. Citing my beloved MSVC again -- 180 megs is a nice sized footprint. Seems pretty big, and to be sure it's fatter than most in my task list. But it's only a
fraction of what MSVC needs to run smoothly. When I do a full rebuild, entirety of the PCSX2 source code ends up being loaded into memory, along with STL, ANSI C, and other such libraries (which dwarf PCSX2's codebase anyway). The total exceeds 150 megs. Additionally for my devel/debug mode builds even the smallest changes require linker invocation, and that requires referencing a lot of object files and libraries -- the entirety of which can easily exceed 300 megs itself. First time after a reboot it takes several seconds to build even a single-file change. Subsequent such modifications are nearly instantaneous, thanks to the disk cache having swapped out a bunch of other background apps to make room for what I'm doing currently.
Fortunately in my case that's also stuff shared between my three instances of MSVC (and indeed, in many users' cases disk cache contents get used by multiple user programs around the same time, as per typical patterns of software use), which is why disk caching is clever and why Windows tends to devote a lot of ram to it (typically about 60-80% in fact, depending on how much ram you have).
Is one bloaty app going to matter much when you have 4 or 6GB of ram? Nah, not really. But when you start accumulating a half dozen or more such bloaty apps, it sure as hell can matter. So I like to be smart, which is something not everyone likes to be, and avoid bloaty apps in favor of nicer, better, more feature-laden alternatives. Now if an alternative is
not nicer and better, and is in fact crappier and ungood compared to a bloaty app, I'll stick with the bloat. But ATI-TT is a case where one can upgrade and reduce system load at the same time.
Choosing to stick with CCC is acceptable. It doe have some pretty images in it's control panel after all. But making excuses as to why you don't feel like it, and trying to pretend you have any idea how complicated the memory system of your PC happens to be by posting a screenshot of Task manager that
doesn't even have the Virtual Memory Size column turned on, and thinking I somehow don't know what I'm talking about, are not very good decisions.
... well unless you have an SSD (solid state drive), which largely negates the need for a large disk cache, and makes most of what I've said here moot. With one of those you're free to run all the bloaty apps you want, and it'll prolly never have any adverse effect on system performance.
Ah yes, the humbling factor of new technology, rendering mass quantities of learned information obsolete.