21 ms·

Firefox fixes save gigabytes of memory on image-heavy pages

440 points by AndrewDucker 13y ago

anentropic 13y ago
Or alternatively... Firefox fail was previously wasting gigabytes of memory on image-heavy pages
- 01Michael10 13y ago
  Gee, the trolls are up early today...
  - morkbot 13y ago
    On one hand true, on the other - it isn't that those fixes are some magic, extra smart hackery (at least on the idea level, dunno about the implementation). Don't load an image that user don't see, remove an image that user saw but don't see anymore - those seem as rather obvious solutions.
    - icebraining 13y ago
      Yeah, and to cure cancer you just need to eliminate the bad cells without affecting the good cells. It's obvious.
      - pritambaral 13y ago
        Except, selectively targeting (bad) cells in a heavily complex system (physiology) that you didn't design and have limited access to makes it tough. Implementing these fixes in FF is easy. They didn't even have to be geniuses to realize it, just keeping an eye on friends (/rivals) would have given them the idea a few years ago. NB: Not criticizing FF devs. They do awesome work! And sometimes, such silly little optimizations can just stay hidden at the back of everyone's minds for ages until showing themselves through a veil of obviousness. But, cancer vs these optimizations? No chance.
        AndrewDucker 13y ago
        The idea of fixing them is easy, the practicalities are clearly not - take a look at the size of the bug reports and patches that go with them...
        pritambaral 13y ago
        I agree it is tricky. But not as bad as curing cancer, by far. Practically, cancer cannot be cured even by multiples of all the effort than went into those two bugs.
        Ygg2 13y ago
        Stretching the analogy a bit too much? The crux of point was - simple ideas can become excruciatingly complex to impossible solutions in practice.
    - AndrewDucker 13y ago
      Obvious, but tricky. Take a look at the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=847223 https://bugzilla.mozilla.org/show_bug.cgi?id=847223 It comes in ten parts, and there's lots of discussion about how to deal with viewports, when to load things in, etc. The original bug (which discarded images that weren't visible) was even worse: https://bugzilla.mozilla.org/show_bug.cgi?id=689623 https://bugzilla.mozilla.org/show_bug.cgi?id=689623
    - Livven 13y ago
      Yeah the original comment isn't all that wrong technically (though not very nice either). Firefox is my main browser but loading long and heavy pages takes noticeably longer than with Chrome or IE and causes laggy scrolling. Glad they fixed it with v26 though, hopefully should land in the beta channel soon.
    - NathanKP 13y ago
      Just determining whether or not the user can see an image is quite tricky when you consider that there are a number of things which could cause it to be invisible to the user and thus safe to remove: * It might be placed as a normal block element on the page but out of the current viewport. * It might have had visibility: hidden CSS statement applied to it. * It might have had display: none CSS statement applied to it. * It might have the alpha channel set to fully transparent and then fade in. * It might be inside a <div> that has overflow: scroll and then have that specific div scrolled such that the image is outside the viewport of that <div> * It might be using top and left CSS properties to animate the position of the element such that it is off the screen. * It might have it's CSS width or height set to 0 so that it can be start out "hidden" and then have animate open. So I wouldn't discount this as just a simple solution because I see a lot of edge cases where things could get confusing just due to the complexity of how many ways there are for a page element to be visible versus not visible.
    - kamjam 13y ago
      The great thing about Firefox is that if something is so obvious, you could also contribute to the development effort...
      - deleted 13y ago
        [deleted]
      - billiam 13y ago
        right on. Please spend as much time reading the bug referenced above as you have this thread, and think about the obvious problems/hard solutions proposed, then make a better one! Just keeping a few million WinXP machines from a recycling barge in Bangladesh for another year would be worth the trouble. and hopefully smarter image handling by everybody's browser/phone/whatever will be a long term result.
icebraining 13y ago
Great news! Many thanks to Timothy Nikkel and all the other Mozilla devs. It's particularly great on Fennec, where the memory constraint is noticeable. For people - like me - who didn't know what B2G was, it's Boot2Gecko, the OS project: https://wiki.mozilla.org/B2G/FAQ https://wiki.mozilla.org/B2G/FAQ
- soapdog 13y ago
  Check out http://firefox.com/os http://firefox.com/os for a user view of Firefox OS and https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS for a Developer view.
- mccr8 13y ago
  For people who don't know what Fennec is, it's Firefox for Android. :)
deleted 13y ago
[deleted]
adamtulinius 13y ago
I wish people would use regular 2d plots for 2d data. Other than that, great news!
- eterm 13y ago
  Technically it's 3D data, with the three axes being {Time, Memory Usage, Version}. But I agree there may be a better way of visualising this data.
  - deleted 13y ago
    [deleted]
  - mattlutze 13y ago
    Technically it's three trials of 2D data, with the axes being Time and Memory Usage. The width of the lines given by the version axis is for visibility, not to encode data. A 2D line graph with 3 colors for the different versions would be an appropriate visualization. This one suffers spatial distortion and is only useful in confirming that yes, they use less memory in step 2 now.
    - mistercow 13y ago
      >The width of the lines given by the version axis is for visibility, not to encode data. Bar graphs do exactly the same thing in a 2D graph. Would you suggest that all bar graphs be replaced by a one pixel wide stacked bar graph? Of course not, because even though the samples in a bar graph are discrete, they convey order. It's the same here. The width of the lines is only for visibility, but the Z position of the lines conveys version order. A 2D line graph would only convey that by labels. And if labels were as useful as visual position, we could just replace all graphs with lists of numbers. I personally found this graph trivial to read and comprehend. The spacial distortion is canceled out by the fact that the differences we're looking at are very large, and the steps axis is spaced out sufficiently to line up the points visually. My only complaint is that it shouldn't be a line graph, as the steps are not continuous.
      - 13y ago
sfjailbird 13y ago
Sounds great - does anyone know how this compares to Chrome (both in terms of approach and results)?
- sanxiyn 13y ago
  Chrome did a variant of this (at least) the last year. Not sure how comparable. See WebKit bug 94240 for example.
- bru 13y ago
  As spyder says in another thread of this post, on the given page (http://congressoamericano.blogspot.fr/p/fotos-do-congresso-americano-iii.html http://congressoamericano.blogspot.fr/p/fotos-do-congresso-a...) Chrome decodes and decodes... the memory usage goes up and up. I was using 1.5GO of memory before closing it (and still far from having loaded everything).
  - kamjam 13y ago
    Do you know if the tabs run in separate processes yet (like Chrome) or will a crash/memory leak/long running script cause the whole browser session to close?
    - kevingadd 13y ago
      They don't in Desktop firefox, they do in Android firefox
nikbackm 13y ago
Good to see continuing improvements in the browser of the free and open net.
neurostimulant 13y ago
> When loading the page, physical memory consumption would still jump to almost 3 GB, because the images are still decoded. But it would soon drop down to a few hundred MB, as the decoded data for non-visible images was discarded, and stay there (with some minor variations) while scrolling around the page. This is a great news. The application that uses the most memory on my machine is the web browser. I wonder if this fix would make scrolling the page less smooth.
- nnethercote 13y ago
  > I wonder if this fix would make scrolling the page less smooth. It shouldn't. But why don't you try it?
mnarayan01 13y ago
Like many of the other Firefox memory changes, this one leaves me feeling a little ambiguous. On the one hand, obviously keeping memory usage down is good. On the other hand, waiting to decompress/decode images until they are visible to the user means that there are obviously going to be performance trade-offs (and also, obviously, design/engineering trade-offs). Speaking just from my personal usage: I don't think there has ever been a time where delaying the image decompression on a page would ever have had any utility for me (at least from a memory standpoint). On the other hand, there have been plenty of times when eagerly performing image decompression would make my browsing a bit smoother. All in all, it seems (from a not-particularly-in-touch outsider perspective) as if Mozilla went from being totally dismissive of memory complaints to being hyper-responsive to memory complaints with no (publicly stated) rationale behind the change. It would be interesting to see the reasoning behind this (if only from an intellectual standpoint), particularly given that in many cases I tend to feel that it would have been better to simply be a bit more diplomatic when rejecting memory-based bug reports.
- dbaupp 13y ago
  I imagine it's good for image heavy sites like Pinterest or Tumblr.
  - mikebonnell 13y ago
    Agreed, it's a huge win there.
- daleharvey 13y ago
  With the capbility being built, if there is a performance tradeoff (I didnt look through the bugs, but imagine it was already thought about), then its now possible to do 'hey you have a load of spare memory' pre decode all the things type optimisations
  - mnarayan01 13y ago
    Good point. I imagine the issues would be more with when to unload an image, though depending on the implementation that might not be particularly problematic either.
spyder 13y ago
I just compared it with Chrome using the example page mentioned in article: In Firefox Nightly at the initial page load it uses around 250 MB memory and with scrolling it stays around that. In Chrome (in Canary too) initial it uses around 300 MB but scrolling keeps filling the memory indefinitely (I stopped scrolling above 1.2GB)
- aktau 13y ago
  Yea, I also noticed that, save for the pages with tons of images, firefox has actually been better than chrome in that respect for the last few releases. Now with this fix, I'm seriously thinking of jumping back. Then I'll finally have my sweet DownThemAll again. Many kudos to the firefox devs, performance and memory-usage is very important, and it seems they realized that before it was too late. Even with my 16GB I'd really like to run an extra VM for development as opposed to letting my browser gobble it all up.
  - patrickaljord 13y ago
    isn't 16GB enough to run an extra VM for dev? also, try docker.
    - aktau 13y ago
      Not when most of that 16GB is in use. At the moment, chrome is using up 3.4GB. Yea, I have a lot of tabs open. Yes, I should work on that. Yes, I'd also like being able to open that many tabs and have my browser perhaps release some of that memory and just reclaim it when I open the tab for reading again. Docker is real nice, although I might go for pure LXC the nex time I build something. But I'm developing on OSX (as many of us, I believe). So _not_ running a VM is not really possible here. I deploy on Linux, and like to have my environment very consistent, hence the VM. Granted, with Docker/LXC I could probably get by with just one VM and a lot of little apps running side-by-side, but that's not how my current setup and projects work, yet. At any rate, less memory used by browser is more memory for me, to use any way I want. I already love the firefox behaviour that when it restores your tabs, it doesn't actually load them until you click on them. Awesome startup speed improvement.
reidmain 13y ago
Is it time to switch back to Firefox from Chrome? I remember when I originally switched around Firefox 3.5.x Chrome was much leaner and faster. Has the pendulum finally swung back the other way?
- dbaupp 13y ago
  It depends how you use it: e.g. I normally have many many tabs open, and Firefox handles that much better on my system than Chromium.
  - culshaw 13y ago
    really? I have about 20 tabs open on Chrome now with no lag, with one tab open in Firefox my whole system grinds to a halt.
    - Wilya 13y ago
      The "many tabs" situation where Firefox performs better than Chrome is more like 50+ or 100+ tabs than 20. People have widely different use cases with tabs. My experience is that performance on Chrome degrades beyond 30 or 40 tabs, though the exact value depends on your system. You can have Firefox open with 400 tabs without too much performance degradation. Many tabs will be swapped to disk or not even loaded, but the tabs you actually use will work just fine. (also, Firefox on Mac seems to perform less smoothly than on other platforms, though I'm not entirely sure why)
      - deleted 13y ago
        [deleted]
      - snogglethorpe 13y ago
        > The "many tabs" situation where Firefox performs better than Chrome is more like 50+ or 100+ tabs than 20. For me it's much sooner... on my work machine with limited memory, firefox is almost always noticeably better after 3-4 tabs, or even fewer when they're memory-hungry sites like gmail. With only 1GB on that machine, I tend to be hyper-sensitive to memory usage, and unfortunately chrome tends to basically use up all memory on the system once I reach 8-9 tabs. FF gets a fair bit further. The upside of chrome on that machine, however, is that the process-per-tab thing makes much easier to control memory usage: although tabs chew up memory quickly, closing a tab gives you back all the memory it was using, whereas with FF the relationship between closing tabs and giving memory back to the system is much fuzzier....
PedroBatista 13y ago
Excellent news! This problem was so bad that after only a couple pages of porn gifs on Tumblr i had to open Chrome to keep the smut going.
warcode 13y ago
I returned to Firefox (Aurora) a couple of months ago, but i am currently starting to inch towards chrome again. While reduced memory usage is good, it doesn't help when has major problems handling multiple open tabs with flash player, has problems with javascript-heavy pages, and the firefox profiles STILL degrade in performance over time. I really don't want to remake my FF profiles every 2 weeks just to avoid performance issues.
- cpeterso 13y ago
  What Firefox add-ons are you using? You shouldn't need to rebuild your profile every two weeks. How much does rebuilding your profile improve performance?
rplnt 13y ago
Tried the page with Opera (12.xx) and it peaked at around +850MB and within seconds backed down to the initial value (+0MB). No change during scrolling. How is that possible? Does the browser hold bigger pool and just got rid of other stuff?
Sarkie 13y ago
Chrome is starting to be a nightmare to use, might have to go back to Firefox. I can't get meaningful help if it freezes or doesn't load and it can't deal with 50% of the router pages, IE only :(
ksec 13y ago
For those Complaining about Firefox Responsiveness. There are e10s Reboot ( Process Per Component or tab ) that they are working on. Generational GC, New Graphics Backend etc.
acdha 13y ago
Interestingly, this optimization is already unnecessary if you are using the common technique of setting the CSS background-image on an element rather than using IMG src - on Chrome, Firefox and even Internet Explorer memory usage will be stable on a grid of images that way and, as a bonus, you trivially get cross-browser scaling and centering for vertically scaling thumbnails to be the same size.
Avitas 13y ago
Nice. This means that SeaMonkey will be getting these updates a day or two after FF.
chestnut-tree 13y ago
Completely unscientific test: if I load the following website in Firefox 24 (on Windows 8), the page scrolls very sluggishly (as it did in previous Firefox versions). The same page scrolls fine in Chrome. I don't know what is causing the difference. Is it the images? Or something else? For info, Firefox is my main web browser and I have never switched to Chrome (nor do I intend to). Warning - the website is ridiculously image heavy (it's a gallery of Android app screenshots) http://androidniceties.tumblr.com/ http://androidniceties.tumblr.com/
trustfundbaby 13y ago
If Firefox would find a way to let Chrome extensions work in Firefox, that would definitely make it a little easier to switch back and forth, definitely going to try this out though.
mark-r 13y ago
I switched to Chrome recently because Firefox was growing overnight to the point where it started thrashing and becoming unusable. I just checked and it says I already have the latest version. This recent change must not be the whole story.
- what_ever 13y ago
  The latest changes done as part of this are only present on Aurora (Firefox alpha) and the feature is turned off by default. Also, I have my Firefox (Aurora again) running for over a week now on my dev machine with > 50 tabs open an I have had no issues with memory. I suppose there is some problem with one of your add-ons. Try creating a clean profile and see if it's any different.

440 points by AndrewDucker 13y ago

anentropic 13y ago

Or alternatively... Firefox fail was previously wasting gigabytes of memory on image-heavy pages

01Michael10 13y ago
Gee, the trolls are up early today...
- morkbot 13y ago
  On one hand true, on the other - it isn't that those fixes are some magic, extra smart hackery (at least on the idea level, dunno about the implementation). Don't load an image that user don't see, remove an image that user saw but don't see anymore - those seem as rather obvious solutions.
  - icebraining 13y ago
    Yeah, and to cure cancer you just need to eliminate the bad cells without affecting the good cells. It's obvious.
    - pritambaral 13y ago
      Except, selectively targeting (bad) cells in a heavily complex system (physiology) that you didn't design and have limited access to makes it tough. Implementing these fixes in FF is easy. They didn't even have to be geniuses to realize it, just keeping an eye on friends (/rivals) would have given them the idea a few years ago. NB: Not criticizing FF devs. They do awesome work! And sometimes, such silly little optimizations can just stay hidden at the back of everyone's minds for ages until showing themselves through a veil of obviousness. But, cancer vs these optimizations? No chance.
      - AndrewDucker 13y ago
        The idea of fixing them is easy, the practicalities are clearly not - take a look at the size of the bug reports and patches that go with them...
        pritambaral 13y ago
        I agree it is tricky. But not as bad as curing cancer, by far. Practically, cancer cannot be cured even by multiples of all the effort than went into those two bugs.
        Ygg2 13y ago
        Stretching the analogy a bit too much? The crux of point was - simple ideas can become excruciatingly complex to impossible solutions in practice.
  - AndrewDucker 13y ago
    Obvious, but tricky. Take a look at the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=847223 https://bugzilla.mozilla.org/show_bug.cgi?id=847223 It comes in ten parts, and there's lots of discussion about how to deal with viewports, when to load things in, etc. The original bug (which discarded images that weren't visible) was even worse: https://bugzilla.mozilla.org/show_bug.cgi?id=689623 https://bugzilla.mozilla.org/show_bug.cgi?id=689623
  - Livven 13y ago
    Yeah the original comment isn't all that wrong technically (though not very nice either). Firefox is my main browser but loading long and heavy pages takes noticeably longer than with Chrome or IE and causes laggy scrolling. Glad they fixed it with v26 though, hopefully should land in the beta channel soon.
  - NathanKP 13y ago
    Just determining whether or not the user can see an image is quite tricky when you consider that there are a number of things which could cause it to be invisible to the user and thus safe to remove: * It might be placed as a normal block element on the page but out of the current viewport. * It might have had visibility: hidden CSS statement applied to it. * It might have had display: none CSS statement applied to it. * It might have the alpha channel set to fully transparent and then fade in. * It might be inside a <div> that has overflow: scroll and then have that specific div scrolled such that the image is outside the viewport of that <div> * It might be using top and left CSS properties to animate the position of the element such that it is off the screen. * It might have it's CSS width or height set to 0 so that it can be start out "hidden" and then have animate open. So I wouldn't discount this as just a simple solution because I see a lot of edge cases where things could get confusing just due to the complexity of how many ways there are for a page element to be visible versus not visible.
  - kamjam 13y ago
    The great thing about Firefox is that if something is so obvious, you could also contribute to the development effort...
    - deleted 13y ago
      [deleted]
    - billiam 13y ago
      right on. Please spend as much time reading the bug referenced above as you have this thread, and think about the obvious problems/hard solutions proposed, then make a better one! Just keeping a few million WinXP machines from a recycling barge in Bangladesh for another year would be worth the trouble. and hopefully smarter image handling by everybody's browser/phone/whatever will be a long term result.

icebraining 13y ago

Great news! Many thanks to Timothy Nikkel and all the other Mozilla devs. It's particularly great on Fennec, where the memory constraint is noticeable. For people - like me - who didn't know what B2G was, it's Boot2Gecko, the OS project: https://wiki.mozilla.org/B2G/FAQ https://wiki.mozilla.org/B2G/FAQ

soapdog 13y ago
Check out http://firefox.com/os http://firefox.com/os for a user view of Firefox OS and https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS for a Developer view.
mccr8 13y ago
For people who don't know what Fennec is, it's Firefox for Android. :)

deleted 13y ago

[deleted]

adamtulinius 13y ago

I wish people would use regular 2d plots for 2d data. Other than that, great news!

eterm 13y ago
Technically it's 3D data, with the three axes being {Time, Memory Usage, Version}. But I agree there may be a better way of visualising this data.
- deleted 13y ago
  [deleted]
- mattlutze 13y ago
  Technically it's three trials of 2D data, with the axes being Time and Memory Usage. The width of the lines given by the version axis is for visibility, not to encode data. A 2D line graph with 3 colors for the different versions would be an appropriate visualization. This one suffers spatial distortion and is only useful in confirming that yes, they use less memory in step 2 now.
  - mistercow 13y ago
    >The width of the lines given by the version axis is for visibility, not to encode data. Bar graphs do exactly the same thing in a 2D graph. Would you suggest that all bar graphs be replaced by a one pixel wide stacked bar graph? Of course not, because even though the samples in a bar graph are discrete, they convey order. It's the same here. The width of the lines is only for visibility, but the Z position of the lines conveys version order. A 2D line graph would only convey that by labels. And if labels were as useful as visual position, we could just replace all graphs with lists of numbers. I personally found this graph trivial to read and comprehend. The spacial distortion is canceled out by the fact that the differences we're looking at are very large, and the steps axis is spaced out sufficiently to line up the points visually. My only complaint is that it shouldn't be a line graph, as the steps are not continuous.
    - 13y ago

sfjailbird 13y ago

Sounds great - does anyone know how this compares to Chrome (both in terms of approach and results)?

sanxiyn 13y ago
Chrome did a variant of this (at least) the last year. Not sure how comparable. See WebKit bug 94240 for example.
bru 13y ago
As spyder says in another thread of this post, on the given page (http://congressoamericano.blogspot.fr/p/fotos-do-congresso-americano-iii.html http://congressoamericano.blogspot.fr/p/fotos-do-congresso-a...) Chrome decodes and decodes... the memory usage goes up and up. I was using 1.5GO of memory before closing it (and still far from having loaded everything).
- kamjam 13y ago
  Do you know if the tabs run in separate processes yet (like Chrome) or will a crash/memory leak/long running script cause the whole browser session to close?
  - kevingadd 13y ago
    They don't in Desktop firefox, they do in Android firefox

nikbackm 13y ago

Good to see continuing improvements in the browser of the free and open net.

neurostimulant 13y ago

> When loading the page, physical memory consumption would still jump to almost 3 GB, because the images are still decoded. But it would soon drop down to a few hundred MB, as the decoded data for non-visible images was discarded, and stay there (with some minor variations) while scrolling around the page. This is a great news. The application that uses the most memory on my machine is the web browser. I wonder if this fix would make scrolling the page less smooth.

nnethercote 13y ago
> I wonder if this fix would make scrolling the page less smooth. It shouldn't. But why don't you try it?

mnarayan01 13y ago

Like many of the other Firefox memory changes, this one leaves me feeling a little ambiguous. On the one hand, obviously keeping memory usage down is good. On the other hand, waiting to decompress/decode images until they are visible to the user means that there are obviously going to be performance trade-offs (and also, obviously, design/engineering trade-offs). Speaking just from my personal usage: I don't think there has ever been a time where delaying the image decompression on a page would ever have had any utility for me (at least from a memory standpoint). On the other hand, there have been plenty of times when eagerly performing image decompression would make my browsing a bit smoother. All in all, it seems (from a not-particularly-in-touch outsider perspective) as if Mozilla went from being totally dismissive of memory complaints to being hyper-responsive to memory complaints with no (publicly stated) rationale behind the change. It would be interesting to see the reasoning behind this (if only from an intellectual standpoint), particularly given that in many cases I tend to feel that it would have been better to simply be a bit more diplomatic when rejecting memory-based bug reports.

dbaupp 13y ago
I imagine it's good for image heavy sites like Pinterest or Tumblr.
- mikebonnell 13y ago
  Agreed, it's a huge win there.
daleharvey 13y ago
With the capbility being built, if there is a performance tradeoff (I didnt look through the bugs, but imagine it was already thought about), then its now possible to do 'hey you have a load of spare memory' pre decode all the things type optimisations
- mnarayan01 13y ago
  Good point. I imagine the issues would be more with when to unload an image, though depending on the implementation that might not be particularly problematic either.

spyder 13y ago

I just compared it with Chrome using the example page mentioned in article: In Firefox Nightly at the initial page load it uses around 250 MB memory and with scrolling it stays around that. In Chrome (in Canary too) initial it uses around 300 MB but scrolling keeps filling the memory indefinitely (I stopped scrolling above 1.2GB)

aktau 13y ago
Yea, I also noticed that, save for the pages with tons of images, firefox has actually been better than chrome in that respect for the last few releases. Now with this fix, I'm seriously thinking of jumping back. Then I'll finally have my sweet DownThemAll again. Many kudos to the firefox devs, performance and memory-usage is very important, and it seems they realized that before it was too late. Even with my 16GB I'd really like to run an extra VM for development as opposed to letting my browser gobble it all up.
- patrickaljord 13y ago
  isn't 16GB enough to run an extra VM for dev? also, try docker.
  - aktau 13y ago
    Not when most of that 16GB is in use. At the moment, chrome is using up 3.4GB. Yea, I have a lot of tabs open. Yes, I should work on that. Yes, I'd also like being able to open that many tabs and have my browser perhaps release some of that memory and just reclaim it when I open the tab for reading again. Docker is real nice, although I might go for pure LXC the nex time I build something. But I'm developing on OSX (as many of us, I believe). So _not_ running a VM is not really possible here. I deploy on Linux, and like to have my environment very consistent, hence the VM. Granted, with Docker/LXC I could probably get by with just one VM and a lot of little apps running side-by-side, but that's not how my current setup and projects work, yet. At any rate, less memory used by browser is more memory for me, to use any way I want. I already love the firefox behaviour that when it restores your tabs, it doesn't actually load them until you click on them. Awesome startup speed improvement.

reidmain 13y ago

Is it time to switch back to Firefox from Chrome? I remember when I originally switched around Firefox 3.5.x Chrome was much leaner and faster. Has the pendulum finally swung back the other way?

dbaupp 13y ago
It depends how you use it: e.g. I normally have many many tabs open, and Firefox handles that much better on my system than Chromium.
- culshaw 13y ago
  really? I have about 20 tabs open on Chrome now with no lag, with one tab open in Firefox my whole system grinds to a halt.
  - Wilya 13y ago
    The "many tabs" situation where Firefox performs better than Chrome is more like 50+ or 100+ tabs than 20. People have widely different use cases with tabs. My experience is that performance on Chrome degrades beyond 30 or 40 tabs, though the exact value depends on your system. You can have Firefox open with 400 tabs without too much performance degradation. Many tabs will be swapped to disk or not even loaded, but the tabs you actually use will work just fine. (also, Firefox on Mac seems to perform less smoothly than on other platforms, though I'm not entirely sure why)
    - deleted 13y ago
      [deleted]
    - snogglethorpe 13y ago
      > The "many tabs" situation where Firefox performs better than Chrome is more like 50+ or 100+ tabs than 20. For me it's much sooner... on my work machine with limited memory, firefox is almost always noticeably better after 3-4 tabs, or even fewer when they're memory-hungry sites like gmail. With only 1GB on that machine, I tend to be hyper-sensitive to memory usage, and unfortunately chrome tends to basically use up all memory on the system once I reach 8-9 tabs. FF gets a fair bit further. The upside of chrome on that machine, however, is that the process-per-tab thing makes much easier to control memory usage: although tabs chew up memory quickly, closing a tab gives you back all the memory it was using, whereas with FF the relationship between closing tabs and giving memory back to the system is much fuzzier....

PedroBatista 13y ago

Excellent news! This problem was so bad that after only a couple pages of porn gifs on Tumblr i had to open Chrome to keep the smut going.

warcode 13y ago

I returned to Firefox (Aurora) a couple of months ago, but i am currently starting to inch towards chrome again. While reduced memory usage is good, it doesn't help when has major problems handling multiple open tabs with flash player, has problems with javascript-heavy pages, and the firefox profiles STILL degrade in performance over time. I really don't want to remake my FF profiles every 2 weeks just to avoid performance issues.

cpeterso 13y ago
What Firefox add-ons are you using? You shouldn't need to rebuild your profile every two weeks. How much does rebuilding your profile improve performance?

rplnt 13y ago

Tried the page with Opera (12.xx) and it peaked at around +850MB and within seconds backed down to the initial value (+0MB). No change during scrolling. How is that possible? Does the browser hold bigger pool and just got rid of other stuff?

Sarkie 13y ago

Chrome is starting to be a nightmare to use, might have to go back to Firefox. I can't get meaningful help if it freezes or doesn't load and it can't deal with 50% of the router pages, IE only :(

ksec 13y ago

For those Complaining about Firefox Responsiveness. There are e10s Reboot ( Process Per Component or tab ) that they are working on. Generational GC, New Graphics Backend etc.

acdha 13y ago

Interestingly, this optimization is already unnecessary if you are using the common technique of setting the CSS background-image on an element rather than using IMG src - on Chrome, Firefox and even Internet Explorer memory usage will be stable on a grid of images that way and, as a bonus, you trivially get cross-browser scaling and centering for vertically scaling thumbnails to be the same size.

Avitas 13y ago

Nice. This means that SeaMonkey will be getting these updates a day or two after FF.

chestnut-tree 13y ago

Completely unscientific test: if I load the following website in Firefox 24 (on Windows 8), the page scrolls very sluggishly (as it did in previous Firefox versions). The same page scrolls fine in Chrome. I don't know what is causing the difference. Is it the images? Or something else? For info, Firefox is my main web browser and I have never switched to Chrome (nor do I intend to). Warning - the website is ridiculously image heavy (it's a gallery of Android app screenshots) http://androidniceties.tumblr.com/ http://androidniceties.tumblr.com/

trustfundbaby 13y ago

If Firefox would find a way to let Chrome extensions work in Firefox, that would definitely make it a little easier to switch back and forth, definitely going to try this out though.

mark-r 13y ago

I switched to Chrome recently because Firefox was growing overnight to the point where it started thrashing and becoming unusable. I just checked and it says I already have the latest version. This recent change must not be the whole story.

what_ever 13y ago
The latest changes done as part of this are only present on Aurora (Firefox alpha) and the feature is turned off by default. Also, I have my Firefox (Aurora again) running for over a week now on my dev machine with > 50 tabs open an I have had no issues with memory. I suppose there is some problem with one of your add-ons. Try creating a clean profile and see if it's any different.