Profile size: big offenders

Taras Glek tglek at
Mon Feb 3 09:24:50 PST 2014

> Richard Newman <mailto:rnewman at>
> Saturday, February 1, 2014 8:12
> I pulled my living profile off my personal phone so I could take a 
> snapshot of the disk usage, in aid of our campaign against fatfennec.
> Android reports:
> Total: 386.00MB
> App: 33.88MB
> Data: 352.00MB
> Historical peak is over 400MB.
> Of that, my Mac reports that 240MB is my profile. I'll investigate the 
> remaining 112MB when I can, but it's presumably "shit left in the raw 
> app directory, prefs, and Sync metadata DBs".
> Below is an annotated list of the big offenders, with my snide 
> comments. "**" indicates something we should be attacking.
> CCing Taras because this is the kind of stuff he digs, and it's ammo 
> for his war on *.sqlite! This affects desktop, too.
Waiting on Vladan to publish a document on reasons to not use SQLite and 
available alternatives :)
> High-level conclusions:
> * We need to aggressively wipe caches. They're growing until we hit a 
> storage limit, but that growth both makes us look bad and also affects 
> cache seek time, to our detriment. Some of the telemetry numbers for 
> cache hits and misses are bad -- we're looking at ninety-fifth 
> percentiles in the multiple second ranges for both hits and misses, 
> which is worse than having no cache at all.
> * We have too many databases -- especially ones where both the memory 
> and disk footprint would be reduced by just switching to JSON on disk.
> * We don't control our WAL/journal sizes enough. We're routinely 
> doubling the size of our DB footprint due to WALs.
Compressed JSON files are a very attractive solution in terms of 
performance and footprint. I think gives us all APIs 
needed for this.
> * We need to clean shit up when it's dead.
Should make addons(and gecko) register their files so we can have clear 
ownership instead of doing this on a per-feature basis.
> I encourage y'all to pick something that particularly irks you and 
> make some progress on figuring out why it's big and what we can do 
> about it. I know Wes was working on some additional pruning, but this 
> is a big and continuing effort, so help is appreciated.
Why not have mobile drive this footprint-reduction effort? We only care 
about perf on desktop.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <>

More information about the mobile-firefox-dev mailing list