Figure out why memory stays high after a fresh sync of bookmarks

RESOLVED FIXED in 0.8

Status

Cloud Services
General
P2
normal
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: Mardak, Assigned: Mardak)

Tracking

unspecified
Points:
---
Bug Flags:
blocking-weave1.0 +

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

9 years ago
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..

Updated

9 years ago
Priority: -- → P1
(Assignee)

Updated

9 years ago
Assignee: nobody → edilee

Updated

9 years ago
Target Milestone: 0.6 → 0.7

Updated

9 years ago
Priority: P1 → P2
(Assignee)

Updated

8 years ago
Flags: blocking-weave1.0+
Target Milestone: 0.7 → 0.8
(Assignee)

Comment 1

8 years ago
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
(Assignee)

Comment 2

8 years ago
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.