nsCacheEntry reports its Size as mDataSize + mMetaData.Size(). However, it also holds a pointer to an nsCString (mKey) which it keeps alive. When testing on popular websites like google.com, you often see mKey be 300-400 bytes in length. As a result, in many cases the size of mKey is of the order of what nsCacheEntry reports as its size. In other words, there is a potentially significant amount of memory that is used but not reported to about:cache, and not taken into consideration for how many entries to keep in the cache (but this isn't technically a leak). In a simple benchmark (see 'test page' attachment in bug 634642, run over hundreds of page loads), it looks like mKey is an additional 20% over the reported size of nsCacheEntry.

Patch makes nsCacheEntry::Size() take into account the length of mKey, so it more accurately represents how much memory the nsCacheEntry uses.

Comment on attachment 519252 [details] [diff] [review] patch Looks good on try. biesi, can you please take a look (or tell me who I should ask, I'm not sure who reviews netwerk/cache stuff)?

Requesting blocking-fennec since this can save 1MB of memory in some cases (we allow 1MB for memory cache, and the amount of memory actually used can be twice as much due to these strings).

Lets get this in to our next release

Comment on attachment 519252 [details] [diff] [review] patch Yeah, cache patches get reviewed by me or one of the other necko peers