Firefox fixes save gigabytes of memory on image-heavy pages
blog.mozilla.org
blog.mozilla.org
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)
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.
Chromebooks do a great job of this -- inactive tabs are often freed when memory is needed elsewhere, and reloaded as necessary. I wonder if that feature is going to come to Chrome outside of ChromeOS.
For now if you want to run docker on your Mac, the best bet is to use Vagrant + virtualbox (or fusion if you have the provider). This means you have to run another VM to run docker which defeats the purpose of the suggestion of running Docker, so you don't have to run another VM instance.
But then, you can run a single VM with any number of Docker containers inside. Depending on what you are doing, that could be a win.
* Unresponsiveness due to one tab thrashing
* Bad use of screen-space (bookmarks always visible, cannot disappear titlebar like in Chrome [there's only a Windows extension for that], menu-bar takes up another bar of space by default)
* Launching firefox has stop-the-world behavior to check/update extensions -- interrupting your flow when you need your browser most
* Some extensions still require restarts
These are the ones I remember off the top of my mind, I'm sure there were more...
I really tried going back to Firefox, but the cumulative pain of all of these made me go back to Chrome.
View -> toolbars -> bookmarks toolbar (uncheck)
> menu-bar takes up another bar of space by default
View -> toolbars -> menu bar (uncheck)
You can move the nav buttons yourself: right click on a toolbar -> Customize.
I wonder if this is not available on my platform (MacOS).
Edit: aah got it. The OP mentioned that you have to use 'Nav bar on title bar' extension along with tree style tabs.
* to disable addon auto-update check - about:addons > wrench: uncheck "update addons automatically"
With browsers I think it's easy to become entrenched; not that that's necessarily bad.
Thanks for the second tip, if I try Firefox again I'll do that. Is it possible to get auto-updates at browser shutdown or in the background, when it doesn't interrupt my flow? I would probably forget to ever update them if it's completely disabled...
browser.tabs.closeButtons;2
Also, I got the (subjective) feeling that Firefox was becoming sluggish as I had 6-7 addons. I might be wrong, but that would mean Firefox is sluggish in general.
Firefox has had years to catch up to Chrome with these issues, why haven't they?
Wayland matches the Windows/OS X behavior (probably because it's easier to just accelerate one big rectangular canvas the process draws on), so who knows what will happen as that catches on.
Or even not trashing. When one tab asks for username/login with a pop-up ("Authentication Required" one) and you have it saved in some email opened in another tab you can't switch to email tab until you kill the login one. I call it "god window" (god tab in this case) pattern. Very typical for most old and some new Windows desktop apps.
Chrome handles it perfectly.
https://bugzilla.mozilla.org/show_bug.cgi?id=613785 open bug for it
So, yeah, I guess you didn't really try. Perhaps you're just attached to Chrome.
Also, checking for updates when I start my browser is the worst possible time UI-wise. I start my browser when the site I want to visit is at my fingertips, and my working memory is fading as I am waiting for my computer. How do you customize this away?
Sure, the bookmarks bar being always-visible or never-visible is a minor defect, but it is still worse than Chrome's show-in-new-tabs behavior. Showing menu bars and window decorations by default shows bad judgement, but indeed that wasn't the reason I couldn't stay with Firefox. It felt slower, had annoying wasteful window decorations, started with annoying extension version checks, and let bad web apps interfere with all my tabs.
Do you have actual responses for my actual points besides "you didn't really try"?
https://www.mozilla.org/en-US/firefox/fx/?utm_source=firefox...
1) Chrome's behavior where you get bookmarks bar in new tabs is far more useful.
2) Even without the bookmarks' bar, I have 4 bars (window decorations, menu bar, tab bar, URL bar), whereas Chrome has 2 (tab bar + window decorations, URL bar).
Screen-space is still wasted compared to Chrome, and you don't get bookmarks in new tabs.
I have just two bars[2] for either browser, enough real-estate for me (wish I had a high resolution though).
[1]: https://support.mozilla.org/en-US/kb/pinned-tabs-keep-favori... [2]: http://i4.minus.com/i4lX5yMWuwoGi.png
Slightly customized Firefox 24: 54 [1]
Chrome 31: 61
IE10: 55 [2]
Opera 12: 61
[1] http://i.imgur.com/eBiIZHc.png (Also, no close button on tabs and they shrink down to the size of pinned tabs. All other browsers do that shrinking stuff by default. There used to be a property for that, but one developer decided to remove it. Now you need a custom userChrome.css and other voodoo.)
[2] Sounds close, but 50% of that space are actually unused. There is a lot less room for tabs.
Also, Firefox requires losing the bookmarks tab completely, whereas Chrome has a saner default of having it appear in new/empty tabs.
Here is a screenshot of how my firefox23 window looks like under Ubuntu/KDE4.
[1]: http://jelv.is/browser-screen-usage.png
Extensions require a restart to be installed, perhaps, but that doesn't seem to be a big issue: you only install any given extension once. If you want to install a bunch at the same time, you only need to restart once.
I agree the restart is a minor issue, as is the menu bar showing by default, as is the bookmarks bar being always/never there (rather than the more sensible Chrome behavior), as is the interruption of my workflow when Firefox decides to check for updates when I start it, as is the relative laggy UI, ... But these issues add up to a worse experience. Worse by enough that despite wanting to avoid Chrome, I came back to it :(
[1]: http://oxygenkde.altervista.org/
There are also some Firefox-specific extensions I can't live without any more, the main one being KeySnail[2] which gives me Emacs-style keyboard shortcuts.
Hacker News could've made their font declaration have a fallback (like "font-family: Verdana, sans-serif;") and things would look way better by default.
As for me, I solved it by editing userContent.css and adding a font-declaration for Hacker News myself. (or you could use something like the Stylish addon)
All in all, I'd say it's the fault of website creators.
When rendering can't keep up with your rate of scrolling, Chrome will display the part that has been rendered so far and display a checkerboard pattern for the not yet rendered part. Previously, Chrome would just flip the display buffers less often if rendering can't keep up.
Chrome may be inefficient with memory but I could manage this by closing the tab. Firefox would retain the memory even after the tab has been closed for some time.
Firefox is a lot better these days.
Lets say you have 200 tabs open, check your computers memory usage, close all of the tabs but one and see how much your memory usage drops. Then close that last tab (or fully quit the program on a mac), and see how much memory you get back.
I typically get about 1/4-1/2 of my total RAM back after closing the program entirely.
Chrome used around 2.5 GB on my machine.
For people - like me - who didn't know what B2G was, it's Boot2Gecko, the OS project: https://wiki.mozilla.org/B2G/FAQ
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.
> 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!
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.
I switched from Chrome to Firefox a couple of months ago for its ability to handle more tabs without slowing/crashing, and for its better performance with image-heavy pages. So, for me, it's not just "who cares?" it's a killer feature.
Basically, my tabs are bookmarks, except tabs are integrated into the web-browser better.
The main usability problem with bookmarks over tabs AFAIC is that the bookmark UI does not encourage pruning bookmarks, so most become stale over time.
Another idea I've been kicking around for a while is "tab decay". Have tabs start to decay and close themselves after not being viewed for a configurable amount of time. 1 month would probably do it for me, it would save me a lot of cleanup time.
Because, as the parent posts point out, tabs take up memory and can cause the browser to become sluggish.
Who said he doesn't?
The browser not using available memory means that other processes on the system have the memory available to use. For those of us who may have the browser running while something else is actively running on the computer, that's potentially pretty important.
4GB seems to be the threshhold right now. Windows consumes maybe 0.5-1GB, budget 0.5-1GB for a handful of other programs, bloat Firefox up to 1-1.5GB, and suddenly you're swapping. (Naturally the OS does not wait right up until you have 4GB of RAM consumed to start swapping, it seems to start around 3GB)
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
If you have any examples where the linked changes causes performance degradation, you should try reporting it to the developers.
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
The reason why I call the Firefox fix a workaround is because the proper way to solve the problem of 2 GB of image data on a page is by using a UITableView style wrapper.
But HTML 5 doesn't have such an element for us to make use of. The proper fix would be to add such an element to HTML itself, but obviously that's something that takes years to do and to get it adopted across all browsers.
So in the meantime tricks like what Firefox is doing are nice to help prevent inexperienced web developers who create abominably inefficient webpages from consuming too much system resources when an unfortunate victim downloads the page.
I guess what I'm trying to say is that this isn't a workaround - it's one of the primary reasons HTML and CSS are architected in the way that they are. This has nothing to do with helping inexperienced web developers and everything to do with preserving the declarative nature of basic web content.
I don't know what their internal rationale is.
"Memory is cheap," we like to say, but it's really only true if you're not wasting it like crazy all the time. Ten years ago you could surf the web with 512MB of RAM; now we're getting to the point where 4GB isn't considered enough. If 4GB now costs the same as 512MB then, then in the sense of "dollars worth of memory required to perform function X acceptably," memory hasn't actually gotten any cheaper.
If you can get performance that used to require 4GB down into 1GB, you've upgraded the performance of a bunch of older and low-budget devices from "barely usable" to "fine."
Take the big-picture view: updates like this can actually result in a slower flow of "obsolete" computers and devices into the landfills. This is one of those bottlenecks where a little good engineering can have really disproportionate positive aggregate effects.
This sort of thinking has been one of the selling points of desktop Linux for a long time. I wish Microsoft thought more like this.
Needless to say, I'm very happy about this firefox news. AS somebody who routinely runs a lot of apps (and more than a few memory hungry ones) I want every app to be a freaking memory frugal as it possibly can, and be a good citizen when RAM has to be shared between apps.
Playing the whole "Unused RAM is wasted, take up as much RAM as you can" mindset is fine if you only run one app at a time, but, really, who the f%!# actually does that???
I suspect that being a company that wants to have a unified code base for their browser and that is now newly pushing a browser-centric OS for smartphones may explain this, at least in part.
In fact, it's fortunate that MemShrink had been up and running for a while because it meant we had already fixed a lot of leaks and inefficiencies, and we had good tools for identifying memory problems in Firefox OS.
Did you do any tests for animation performance, and test that preloaders are not affected? Are these issues addressed?
Hardware accelerated decoding(like IE, and image viewers use) would help. Much modern hardware can do the whole decode-resize step in dedicated hardware.
For software only, an improvement is resizing in jpeg-space to the exact size required. It is much faster than decoding the entire jpeg (eg 5 megapixels 2MB jpeg, into 20MB of uncompressed image data) then only displaying it at 320x200 pixels(1MB at the 16bit needed for this YUV data). You can resize the smaller jpeg-space data, then not have to allocate that 20MB of data (perhaps never going back to the OS).
As well, some images compress very nicely with hardware texture compression (but many look awful). There are heuristics that can be used to decide the best type of texture to use based on the image data.
Why turn 6bit-16bit per pixel jpeg data into 32 bit per pixel data? It only takes more memory and is slower to draw. Surely jpeg usage is common enough to special case its handling?
Good luck!
Other than that, great news!
But I agree there may be a better way of visualising this 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.
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.
To the other points, no, not all bar graphs do the same thing. Bar graph bars are often the width they are due to data binning, where the width has significance.
The graph was trivial, but made less clear by the 3D isometric projection. the spatial distortion is reduced but not canceled out by the space.
3D pie charts share the same failure. Yes, as long as the tilt is slight, they are still mostly readable. But it will make "closer" wedges appear larger and "farther" wedges appear smaller. It's visual dishonesty and unnecessary.
Just because one can finagle understanding out of a visualization does not make it a good visualization.
A histogram of a normal distribution (say, mean lifetime of a particle) is a 1D histogram. You would have counts of decays vs time. In your example, that would be 2D, but it's not.
A 2D histogram would be more like a heat map. The X axis would be time, y axis version, and the (x, y) value would be memory.
More importantly, it wasn't intended to be a rigorous data representation because the results vary significantly between runs. I was just trying to communicate the results in an approximate fashion; the improvements are dramatic enough that approximate is good enough, IMO.
And in case anyone is thinking about suggesting errors bars: please don't.
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)
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....
Firefox currently uses about 3GB memory, which means I have plenty of memory left on my computer. So I do not think memory usage in the general case is so bad for Firefox and neither is scalability or performance. The problem Firefox historically has had and still to a degree has is lack of responsiveness.
I hit the 3GB limit pretty much daily, FF crashes, I start it up again, back come my 200 tabs, thankfully not all loaded at once!
I'll admit I know the cause of the problem, Reddit Enhancement Suite, but I'd rather have FF crash daily than go without RES.
You can't possibly have your attention spread over a hundred sites at a time. Are you using them as bookmarks?
These days however, I have not noticed any of these things for months in Firefox. Really I can't recommend it enough!
What was the tipping point that prompted you to switch back to Firefox? Was Firefox able to import your Chrome history and bookmarks without losing anything?
I never accrued much state in any browser. A handful of bookmarks is all I keep. All the rest is in several services that are independent of the browser. So I don't know about syncing, really. That said, I have since learned to love FF sync, which not only syncs bookmarks and plugins, but also the history and passwords. I even use it with Firefox Mobile on my Android.
If it wasn't Google then it'd be Microsoft. Doesn't really matter besides the fact that it helps them fund the development of their initiatives.
All this "jumping to Chrome" was simply a hype thing IMHO, and I generally don't care about hype.
I have 4 different Chromium profiles, and two different firefox profiles, with different levels of privacy / security. Each profile is also linked to a particular context, for example, a tab each for project A, project B, personal, etc.
Warning - the website is ridiculously image heavy (it's a gallery of Android app screenshots)
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 :(
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.
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.
It shouldn't. But why don't you try it?
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.
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.
Practically, cancer cannot be cured even by multiples of all the effort than went into those two bugs.
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
* 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.