Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox fixes save gigabytes of memory on image-heavy pages

blog.mozilla.org

Post reply on HN
Print view View original

41–50 of 203 posts

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#41

Post by mnarayan01 »

daleharvey wrote: post #22
mnarayan01 wrote: post #19

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 th…

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

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.

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#42

Post by Wilya »

culshaw wrote: post #36
dbaupp wrote: post #29

Earlier quoted context omitted.

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.

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.

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)

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#43

Post by patrickaljord »

aktau wrote: post #27
spyder wrote: post #20

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)

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'…

isn't 16GB enough to run an extra VM for dev? also, try docker.

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#44

Post by shorlander »

culshaw wrote: post #36
dbaupp wrote: post #29

Earlier quoted context omitted.

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.

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.

If Firefox is acting unusually slow resetting your profile will often help: https://support.mozilla.org/en-US/kb/reset-firefox-easily-fi...

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#45

Post by kamjam »

morkbot wrote: post #9
01Michael10 wrote: post #6

Earlier quoted context omitted.

Gee, the trolls are up early today...

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.

The great thing about Firefox is that if something is so obvious, you could also contribute to the development effort...

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#46

Post by dbaupp »

culshaw wrote: post #36
dbaupp wrote: post #29

Earlier quoted context omitted.

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.

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.

As Wilya says, 20 isn't much. A single branch of my tree-style tabs is saying that it has 25 child tabs; and I have ~30 top-level branches (admittedly about half of them are a single tab).

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#47

Post by kamjam »

bru wrote: post #32
sfjailbird wrote: post #8

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

As spyder says in another thread of this post, on the given page ( 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).

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?

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#48

Post by mnarayan01 »

AshleysBrain wrote: post #26
mnarayan01 wrote: post #19

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 th…

If image decoding is asynchronous (don't know - guessing it is already?) and you decode them when they get near to the viewport and not just when they become visible, then it should always be decoded by the time you scroll to it and yet never jank the page. Scrolling a long way really fast probably means there's a small delay while it decodes images, but surely that's worth it to save gigabytes of memory?

> but surely that's worth it to save gigabytes of memory

I'm not sure _save_ is the right word here...using available memory has no particular cost to me over not using it. Of course, the _available_ modifier is relevant, so I take your point.

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#49

Post by snarfy »

reidmain wrote: post #25

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?

Firefox will never ask you to sign-in for the best browsing experience like chrome does. That's when I switched back. You can tell google is an ad company and users are secondary by their default choice of 3rd party cookies. I'd rather not have an ad company developing my browser. The incentives are all wrong.

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#50

Post by Ygg2 »

pritambaral wrote: post #28
AndrewDucker wrote: post #16

Earlier quoted context omitted.

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...

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.

Stretching the analogy a bit too much? The crux of point was - simple ideas can become excruciatingly complex to impossible solutions in practice.
Post reply on HN