641663 - Hidden memory costs of strings in nsCacheEntry instances

Status: RESOLVED FIXED

(Core :: Networking: Cache, defect)

Description

[Alon Zakai (:azakai)]

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.

Comment 1

[Alon Zakai (:azakai)]

Attachment: patch

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

Comment 2

[Alon Zakai (:azakai)]

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)?

Comment 3

[Alon Zakai (:azakai)]

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).

Comment 4

[Stuart Parmenter]

Lets get this in to our next release

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 519252 [details] [diff] [review]
patch

Yeah, cache patches get reviewed by me or one of the other necko peers

Comment 6

[Alon Zakai (:azakai)]

http://hg.mozilla.org/mozilla-central/rev/8dbfdd56997b