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

31–40 of 203 posts

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

#31

Post by dkhenry »

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…

I have been running aurora for a while so I already have this fix. I just tested it and there was no noticeable performance impact for the memory saved.

Chrome on the other hand used all my memory and caused me to start swapping. Any website with lots of images loaded will be impacted by this ( facebook , G+ , tumblr , ... ) so I think its a rather important change

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

#32

Post by bru »

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

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

#33

Post by akjj »

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…

This was a follow-up to an earlier change which also delayed image decompressing. In the description of that change the author wrote: "Andrew McCreight wrote a comment that I can’t find now, but basically he said that on one of his machines, that page was extremely slow and painful to scroll through before the change, and after the change it was smooth and pleasant."

If you have any examples where the linked changes causes performance degradation, you should try reporting it to the developers.

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

#34

Post by NathanKP »

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.

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 that has overflow: scroll and then have that specific div scrolled such that the image is outside the viewport of that

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

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

#35

Post by mccr8 »

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?

Image decoding in Firefox was recently made multithreaded.

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

#36

Post by culshaw »

dbaupp wrote: post #29
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?

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.

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

#37

Post by NathanKP »

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…

We've been using stuff like Infinity.js (http://airbnb.github.io/infinity/) for quite a while now, and it's basic functionality is to improve long scrolling panes by dynamically adding and removing elements (including images) in real time as you scroll to keep the number of elements low and the page responsive. Sites that use this technique usually feel just as responsive as if the site really did have a page with 10,000 items on it instead of a dynamic viewpoint that only shows 100 items as a time.

Personally I think it would be best if HTML developed a spec for an official UITableView style native element. That would provide a way to solve the memory issues and avoid the need for JavaScript hacks like Infinity.js

But in the meantime browser workarounds like this one from Firefox will help avoid the huge memory usage in sites that don't use smart techniques like Infinity.js

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

#38

Post by Derbasti »

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?

For me, it is time. I switched back about a year ago, when Firefox started to not be painful any more, but still was a step back from Chrome. Some tabs would still cause stuttering in the whole app and sometimes scrolling was less than smooth.

These days however, I have not noticed any of these things for months in Firefox. Really I can't recommend it enough!

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

#39

Post by mnarayan01 »

sanxiyn wrote: post #23
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…

https://wiki.mozilla.org/Performance/MemShrink has some reasons. One reason is explicitly "Fewer people will complain that Firefox is a memory hog and that Mozilla ignores memory usage". Even if complaints are technically nonsense, addressing complaints is still important.

Good link...thanks.

> Even if complaints are technically nonsense, addressing complaints is still important.

Totally true, but I don't have to like it...and I can fight against it by complaining about the addressing of the complaints!

Post reply on HN