Bye Bye Allocations

Everyone has been working quite hard lately to get rid of allocations.  I’d like to call out jst, sicking, smaug, dbaron, brendan, igor, and crowder for their help, patches and suggestions over the last few weeks.

Just looking at our startup allocation test, we’ve removed about 100,000 allocations.  Other tests show far, far bigger gains.

allocation graph

We’ve been very successful in converting quite a few heap allocations to use small stack buffers instead.  We’ve found places where we didn’t need to do any allocation at all and just removed themMany of these improvements have come in our DOM and XPConnect code which not only helps reduce fragmentation but also results in performance gains for sites with lots of DOM access (not to mention our UI!).  We’ve also gotten startup speed improvements.

Smaug has done some great work getting content to use arenas.  There are some issues with the arena implementation and we need to get some more stats, but this is a good step in the right direction.

We’ve got more things in the pipeline so I expect this number to continue to drop.

18 thoughts on “Bye Bye Allocations

  1. Mark S

    That’s very exciting to see and hear.

    I’m curious, do you have some numbers of how this quantifies as saves on memory (startup and otherwise) and performance?

    Great work guys. This will make Firefox 3 so much better.

  2. Mike C

    Almost a 20% improvement, great job!

    Any change we can get a “checkpoint” fragmentation graphic of the present windows memory allocation as compared to the ones you took on your initial investigations?

    It would be good to see how the changes implemented so far have helped the memory fragmentation you highlighted earlier.

  3. Pingback: Benchmarking And Testing Browsers | Robert Accettura’s Fun With Wordage

  4. pavlov Post author

    Mike C: I’ve been perfecting my technique for logging allocations between runs and seem to be getting almost consistent results now. I’ll do some followups with where we were vs where we are.

  5. pd

    I dont pretend to understand all this but simple maths tells me you’re reporting almost half a dozen ways you are improving the Firefox ‘footprint’/performance. That is quite simply sensational news. Thanks a bazillion to everyone working their rear off on this.

  6. Havvy

    Your next post, you want to say what allocations are for people who haven’t worked in software for a long period of time?

  7. Sandro Magi

    I posted this in an earlier entry, but it’ll probably get buried. Two papers analyzing memory allocation techniques that are of interest to your effort:

    Reconsidering Custom Memory Allocation

    Scalable Locality-Conscious Multithreaded Memory Allocation

    They both propose generalizations of heaps and arenas. The latter in particular takes great pains to minimize the overheads of small allocations.

  8. Sebastian

    Thanks to all Mozilla you contributors for your great efforts on streamlining the Firefox memory footprint and fixing resource leaks.

    One question: To which extent does this work contribute also to other Mozilla projects, Thunderbird in particular? As the different Mozilla applications share a lot of program components (Javascript engine, XUL UI, etc.), I would expect that the memory management would improve also in the other applications, too.

  9. stevieray

    For the past few days, my Firefox has been megawonky. I routinely run with Task Manager open [a habit I picked up out of necessity — my old pc had minimal memory & hd space], and when I checked with Task Manager, Firefox was using 90%+ of the CPU… even with no activity on any of the open webpages, and its memory usage seemed to grow and grow.

    After much trial and error, I found a blog that makes the CPU usage spike up from its usual single digits to the mid 90’s. Its a Word Press site with a “falling snow” seasonal feature… something the site uses to make the “snow fall” effect causes Firefox to gobble CPU space even when the site is not being viewed [i.e. I click to view another already opened tab].

    Is this a memory leak problem? Or is this a poorly designed website problem? Here’s a link to the blog. I hope this helps in your efforts.

  10. pavlov Post author

    stevieray: That isn’t really a memory leak but a “CPU hog” — I haven’t looked at exactly what the site is doing, but I would guess it is using lots of JavaScript and moving lots of elements around to get its effect (rather than, say, using an animation). As things get more complex they’ll use more CPU. I expect Firefox 3 should be better at the page in question.

  11. stevieray

    pavlov: Thanks for the clarification. I’m relatively new to the world of computers, and I’m still learning exactly what much of the jargon means.

    That particular blog isn’t important to me [except as a curiosity], so I can avoid it easily. I was hoping it would provide a clue as to why my Firefox ate up so much CPU and memory [the few times that has happened], but if it doesn’t? Oh well. Firefox 3 will be out soon… I can shut down, strip out the caches with ATF cleaner, and reopen for a while longer. I will survive [probably]!

    Thanks for your time.

  12. Pingback: Christopher Blizzard » Blog Archive » Firefox 3: rocking on Linux

  13. jmdesp

    @stevieray : I tested with a nightly and there will apparently be much progress on that site. It still tends to take all available CPU when viewed, but it goes down to 60% when in background on my 1,7 Ghz Pentium M. OK, it’s not that great but the best news are probably for memory usage. It fluctuates significantly but periods of grow always stop, and at the end it comes back to the same range as initially.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s