I found that Firefox 27 had huge speed improvements in canvas 2D compared to Firefox 26, at least in Linux without hardware accelerated canvas.
I couldn't find anything related to that in 27's release notes, sooo (still happy though!).
I found that Firefox 27 had huge speed improvements in canvas 2D compared to Firefox 26, at least in Linux without hardware accelerated canvas.
I couldn't find anything related to that in 27's release notes, sooo (still happy though!).
Problem is, this does not convince Average Joe about the slimness of Fx. I asked them to set up a main chart using only the stable ones with the latest changes (allocation), but it was ignored. IMHO that would help them see the what the end user would see over the long course, and A. Joe would see what actually effects him (as he is unlikely to use dev channels).
Edit: the charts also do not show the improvements in Garbage Collection (IGC in Fx16, upcoming ICC and GGC) and the memory management with add-os (Hueyfix in Fx15).
More generally, AWSY is useful for identifying some regressions, but it's one specific, unrealistic workload. You can't use it to judge Firefox's overall memory consumption.
For example, looking at AWSY you'd think Firefox 13 had the best memory consumption. But I guarantee you that Firefox 28 has better memory consumption. In particular, Firefox 28 has fewer bad cases where memory consumption spirals out of control, and those are the cases that really hurt performance and stability. Using 10 or 20% more memory at start-up, for example, isn't a big deal in comparison.
-representative of things Google knows it's faster at
-representative of things Google thinks should be fast and prioritizes... and is thus faster.
or a little of column A little of column b in a feedback loop.My memory was that originally V8 was out-performing everyone else primarily because the initial allocation (into the nursery) was way quicker than anyone else did. Or maybe it was freeing the nodes that die young?
Certainly I remember both SpiderMonkey and Carakan spending huge amounts of time on GC on Splay, and Carakan's massive speed-up came when the object representation was changed (GC actually asymptotically regressed as a result, but in almost every practical case cache-locality (and reduction of memory accesses) outweighed it).
This is awkward since in general I find Firefox's performance to be on par with Chrome, sometimes slightly better, but these charts make me open Chrome and it's a pity since I prefer Firefox.
Maybe HighCharts is not optimized properly for Firefox and of course, those charts being a work in progress are not optimized. But I do wonder, what's the difference here? Is it something about hardware acceleration?
If you are able to provide such a test account, please file a bug at https://bugzilla.mozilla.org/enter_bug.cgi; use "Core :: General" in the "find product" box; and don't worry too much about most of the fields, the title and description are the most important; and also add ":njn" to the "CC" field. Say something like "I can provide login details privately".
If you can do that, I'll try to find the right person to address it.