On my test profile with fat bookmarks, total memory usage jumps up 30MB after doing a fresh sync of the bookmarks. Not sure if it's because we're querying places + sqlite and that causes stuff to stay in memory..
Target Milestone: 0.7 → 0.8
I ran some tests on trunk and used nsIMemoryReporterManager to figure out the levels of malloc/allocated (actively used memory) and malloc/mapped (ready-to-use) after doing repeated "first syncs" of ~2500 bookmarks. So the sync will download those ~2500 records, parse, decrypt, and compare. On my MacBook, the mapped memory would jump up about 30MB after a sync, so that most likely also means the total allocated memory needed about that much memory at some point during the sync. But the in-use memory dropped back down to pre-sync levels. One time after syncing, the total mapped memory actually dropped from pre-sync levels, so I guess Firefox must have exceeded some threshold and started giving back some memory to the OS. So this isn't any worse than loading a bunch of tabs and then closing them and Firefox keeps the memory mapped for future use. And the "first sync" should only happen once, so the "extra"-mapped memory will be re-used by future syncs and normal Firefox page loads. I also switched the client type to "mobile" so "first sync" will only download 150 bookmarks, and this resulted in about 10MB less mapped memory than before, so we have this knob to control our peak memory spikes.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
As a reference, loading digg in a tab results in about a 30MB increase in mapped memory and 15MB increase in allocated.
You need to log in before you can comment on or make changes to this bug.