Quote:
Originally Posted by Michael
Right now Im streaming the moon and its using 4,500k memory.Thats to 60,000k iTunes uses when its running the moon.
|
I'm running a program and it's using 100% of the CPU. I suppose I need a faster CPU too.
[1]
iTunes, on my Powerbook, is using 240+MB of
virtual address space. The statistics monitor says that it's resident in 40+MB of physical memory -- That's only 2% of my total
physical memory. Personally, albeit I'll have to trust the OS X/unix memory management subsystem's decisions, I'd rather see MORE physical memory used and less
paging/swapping for
virtual I/O. However, it could be that the 200M of other pages are for options in iTunes that I am not currently using; thus, proper for it to be paged out of the
working set.
With memory access on the order of nSecs (nanosecond: 1e-9) and disk access on the order of mSecs (milliseconds: 1e-3), memory is a MILLION times faster (1e-3/1e-9 = 1e6). I'm very happy that iTunes is memory resident and consuming that whole 2% of my entire physical memory configuration.
I also have my streaming buffering set to large. iTunes can take and buffer all it wants. I hate stream hiccups.
Also, being multi-threaded (and I've written my share of multi-threaded apps), the thread managers keep
heap set aside for the various threads. I know I can listen to AM on iTunes streaming in and being streamed out to my AirportExpress to speakers while ripping CDs and watching a video. I could probably be downloading from the iTunes store too but I don't buy music on line. The point being that I don't miss a single note of what is playing on AM while all of this is running.
On the PeeCee and Weendoze, who can actually tell what portion of memory an application is
actually using. It's DLL hell. Are all of the DLLs that have been loaded for this application included in the tallies for memory usage by the statistics tool(s) available? I'd doubt it.
I could go into the translation buffer look-aside design, translation buffer mismatch and translation buffer invalidation schemes of each of the OSs and point out the benefits of leaving things in memory, but I don't want to bore you with too many OS design details all at once.
The point herein is that memory use is no metric of performance; however, the more physical memory in today's virtual memory environments, the better the general overall performance. Don't snarl just because a program is using it without a thorough understanding of the nuances of VM.
Footnotes
[1] If you believe this, I am
MORE than willing to see you one.