In bug 658303 I made Storage copy the cache_size across copied connections. That makes sense since the connections should be identical. Plus in the default case (32768 sized pages) that will save memory when the consumer sets a custom page_size smaller than the default (< 2000). The problem is that Places is somehow special here (sigh), we have old databases (included mine) that use 4096 or 1024 pagesize, and this means that: before: - main connection can use up to 50% db size memory (may vary) - cloned connections can use use 2000 * pagesize memory after - all connections can use up to 50% db size memory (may vary) In the 32768 case the connection available memory is reduced from 64MB per connection to half the db size, that's a smaller size. Unfortunately in the 1024 and 4096 cases the cloned connections memory will likely be larger :( In the end, I think I'll put a cap to Places cache_size, and in future (once bug 692487 is fixed) we may just rely on the default value. The good news is that initially the cache_size had been increased for the awesomebar, but since we never cloned its value, we survived with a much smaller size without suffering in performances. If this fix does not end up in FF10, I'll just backout bug 658303 from Aurora.

Comment on attachment 572617 [details] [diff] [review] patch v1.0 Review of attachment 572617 [details] [diff] [review]: ----------------------------------------------------------------- r=me

Per IRC, please post about this to DAF and build forums to get feedback on perf effects.

https://hg.mozilla.org/integration/mozilla-inbound/rev/993c4f411a8a will post once I see this sticking on central.

posted in mozillazine Build forum http://forums.mozillazine.org/viewtopic.php?f=23&t=2357783

and cross-posted to m.d.a.f.