Slashdot Mirror

Also, Proterra was driving in optimal conditions, with no passengers, no stops and a gentle test track. It'd be another story with a fully-laden bus wending its way through a city.

What a load of bullshit. This is like those shitty ARE WE FAST YET? "benchmarks" that show Firefox to be "fast", yet when you actually go to use Firefox it feels so laggy and slow and unpleasant to use.

This isn't an accomplishment to brag about.

And the memory leaks are largely caused by an unsafe extension system that is being replaced by a new, more thread-safe extension system. And the wailing and gnashing of teeth continue.

"Firefox has memory leaks!"
"Fixed the ones in Firefox, the rest are bad extensions (probably AdBlock)"

"Firefox's Javascript is slow!"
"Fixed that"

"Firefox is slow"
"We'll move to a new threading model that's lots faster and requires us to fix our leaky extension model too"

"You're breaking my extensions - why don't you listen to what your users WANT???"
[sigh...]

I don't give a fuck about artificial benchmarks.

There's only one benchmark that matters: using the device or software and seeing if it meets your needs.

Firefox is a great example of how artificial benchmarks can be total nonsense. Firefox fanatics will point to benchmarks like ARE WE FAST YET?, which supposedly show Firefox as being "fast".

But what happens when we actually use browsers like Firefox, Chrome, Safari and Edge? We find very different results! When I run this relevant hands-on usage benchmark, Firefox always feels the slowest to me. The UI lags and it feels like it takes longer for pages to load. I find the scrolling to be chunky. I don't have a good experience.

On the other hand, Chrome, Safari and Edge feel fast. Their UIs are responsive. Pages load and render quickly. Scrolling is nice and smooth. They're a pleasure to use.

If we listened to artificial benchmarks, then we might be led to believe that Firefox is a fast browser. But when we go to try it we can get very different results. In my experience Firefox isn't just the worst-performing out of those browsers, it feels so much slower by a huge margin.

Firefox might look good in some artificial benchmarks, but it totally fails the one and only benchmark that actually matters to me: how it works when I try it out for myself.

http://arewefastyet.com/

http://arewefastyet.com/

How was this modded up? I actually thought it was a troll.
A router != a wireless router or even a wireless access point and wireless support is not "critical functionality" for the device.

Anyway, he mentions that he used the much hyped Ubiquiti WAPs to cover the wireless functionality that he lost from the Nighthawk.
Assuming those live up to the hype then he gave himself a) better routing functionality than the previous solution b) better wireless functionality than the previous solution.
I call that homebrew success.

And then you go into a rant about the quality drop of Linux on the desktop which is kind of bullshit to be honest. I don't know if you remember how bad things were 10-15 years ago but it was definitely much worse than it is now.

Firefox has its ups and downs but it generally increases in performance. The only glaring issue I see with Firefox is not one of it getting worse but that it still doesn't compare favorably to Chrome in terms of multi-tab performance. Hopefully one day e10s will fix that.
And no one is forcing you to use gnome, systemd, or pulseaudio.

You want to restore the "glory" of homebrew projects but you don't even care enough to customize your systems to fit you?

Do you think that Mozilla's Firefox OS would be a better OS for these in-car systems?

It's already the most open mobile OS around, because it's built on the best open standards around, like JavaScript, HTML and CSS.

It's also fast, because it's built upon Firefox technology, which is among the fastest there is.

The UI is also simple and sleek. Lots of seniors use Firefox and love it. If the UI works for them, then it will work for everyone.

Android may have more apps, but Firefox OS is top notch better in so many other ways.

And here I was thinking they forked node.js to get away from the V8 engine which is no longer the fastest.

Quite close: http://arewefastyet.com/

In ideal conditions, C++ compiled to JavaScript, using asm.js, can be almost as fast as an 'ordinary' build of the C++ code.

Chrome's memory usage has increased tremendously over it's lifetime, more so that Firefox is leaner on memory than Chrome and starting to lose it's edge in the quickness department (I use Firefox a lot more than Chrome(ium) and even at cold start for both browsers Firefox is loaded up before Chromium has even appeared). Firefox has come a long way since the first release of Chrome (see https://areweslimyet.com/ and http://arewefastyet.com/) It's amazing what competition can do! Speaking of which, does Slashdot report on new versions of other browsers or is Chrome get special treatment since it's the most popular (pushed) browser?

And by "Mozilla's stats" I am referring to their internal benchmarking using Kraken (Mozilla/Firefox), Sunspider (Apple/Webkit), and Octane (Google/Chrome). Mozilla owns and operates Are We Fast Yet.com and has a nice JS performance over time comparing each JS engine.

Do note that this is just JavaScript and not the whole shebang, but these days, they're pretty close. The JS section of Tom's review uses one of these JS tests and has similar results (though they discard its findings). Tom's does conclude that Chrome beats FF handily here.

I'm pretty surprised to see Chrome beating Firefox handily in JS and HTML and memory efficiency and standards and security yet losing overall. Perhaps too much weight was put into the hardware acceleration piece? Perhaps Tom's forgot that FF startup isn't so good when you load lots of addons (as most do)? My reading of those is that Chrome is the clear winner ... and I'm a Firefox fan (for usability, security, and privacy, mostly via addons).

I found it remarkable that the benchmarks only compared to earlier versions of the Firefox JavaScript implementation. A comparison with JavaScriptCore and v8 can be found at http://arewefastyet.com

... The many good plugins.

I already know this isn't starting out well, given you've called the extensions plugins.

Hate: A single tab can hang the whole browser.

A phenomenal amount of work is going into improving this.

No convenient way to view an image with the wrong MIME type in the browser anyway.

that took 2 seconds to find

Too little and dumbed down settings.

about:config

No more status bar.

It's now the add-ons bar

Still no good debugging tools

You're right with this one. Fortunately it'll be in Firefox 15 releasing at the end of this month, play with it in the beta right now

The weird branding thing they do that caused Archlinux to not call it Firefox but various other lame names in the past (are they for open source or what?).

Trademarks have nothing to do with the code being open sourced. Users are safer because Mozilla can defend the trademarks.

No more innovation (why not try things like multiple tab groups or so

You mean like Panorama that's been there since Firefox 4? (Ctrl Shift E)

The Android version sometimes crashes and once made the whole phone reboot after a crash.

In about:crashes there are links to each crash report, perhaps you can visit irc://irc.mozilla.org/mobile and share those links to help improve it.

its slowness.

If you meant responsiveness, see my first linked answer. If you just mean javascript speed, the Ionmonkey js engine is coming along nicely.

I'm probably missing many things :)

Just one. Firefox.

Of cause they are working on making Firefox faster. There is even a site set up for tracking progress in Javascript performance improvements.

http://www.arewefastyet.com/?a=b&view=regress

> I bet Moz is using the crippler compiler.

You lose.

Mozilla uses gcc for Linux and related platforms, Visual Studio for Windows, and Apple's gcc for Mac OS/X. The Solaris contrib builds are built with the Sun Studio compiler (or whatever it's called these days).

x86_64 is regularly benchmarked, and you can see perf improvements/works on various platforms at http://arewefastyet.com./

Additionally, if you are aware of specific x86_64 performance problems, you should bring them to the attention of the folks at Mozilla (via Bugzilla).

Also, "runs like shit" does not count as specific.

Is it a coincidence that Google wants you to move to a new programming language at the same time that Mozilla has essentially caught up to Google Chrome in JavaScript performance? And when Mozilla has tons of new performance improvements on the way in IonMonkey engine?

Google wants their competitors and other developers on a HTML ("continuously evolving standard"), HTTP (replace with SPDY), JavaScript (replace with Dart) treadmill.

This says 64-bit is faster JavaScript than 32-bit:
http://arewefastyet.com/

I've been using the beta for awhile, and from the moment I installed it it seemed significantly faster to me, and to most people:
http://input.mozilla.com/en-US/release/

And there is plenty of data to support it:
http://arewefastyet.com/?a=b&view=breakdown

Pretty much! Maybe that could be a bit more explanatory, but the blocker currently is that their Linux test box charts are rather broken.

You mean like http://arewefastyet.com/?

That's not massively hard. Before someone could do that you just need to define what "speed/etc" means so that it is both measurable and meaningful in relation to real world web usage. Now _that_ is difficult.

If a collection of javascript test cases is enough for you, please see www.arewefastyet.com.

http://arewefastyet.com/ tracks the new chrome crankshaft.

The reason the 64 bit machine (dropdown on lower left) is slower at kraken is I think crankshaft isn't 64 bit yet,

Anyway, if you look at the historical AWFY, Apple's engine has been pretty consistently on top on sunspider, the margins are pretty thin though due to the shortness of the tests, something both Firefox and Chrome complained about.

I haven't run kraken on the new crankshaft recently (where it appears it would kick ass) but I did run it a few months ago...
http://m8y.org/tmp/kraken.xhtml

Javascript performance - I don't know about on a Mac specifically, but in generally, it's much faster with FF 4's latest betas than it was with 3.6.x. For general comparisons from a few months back trunk code during TraceMonkey+JaegerMonkey integration, see http://arewefastyet.com/ . It's fast now. The extra second of startup time is confusing as an argument either for or against something - this is one second, once every few days or so. Seems kind of irrelevant to me - performance of rendering is the most important thing, Javascript performance secondary, and stuff like startup performance tertiary unless it's really bad.

Not sure about Mac rendering performance, but on Windows, FF is much faster than Chrome or Safari and has been for ages. Javascript performance lagged signifcantly until recently, and they are now all so close as to be irrelevantly different unless you like compiling kernels in your web browser or similarly silly activities.

Without intending to start a flame war, I wish the programming side of computing was as interested in making things smaller and faster in code.

I don't think it's as bad as all that. Believe me, I would love it if all the software I used were trimmed-down and brilliantly optimized. There is indeed quite a lot of software that is bloated and slow. But it really just comes down to value propositions: is it worth the effort (in programming time, testing, etc.)? For companies, it comes down to whether making the software faster will bring in more sales. For many products, it won't bring in new sales (as compared to adding some new feature), so they don't bother.

But in places where it does matter, there actually is some good competition. In browser rendering, for instance, the big players are all competing to improve performance (e.g. Mozilla). Think even of something as horribly inefficient as Adobe Acrobat Reader... It's inefficiency has in fact led to the creation of lighter-weight alternatives (e.g. Sumatra or FoxIt). Another example is in graphics: there are all kinds of brilliant and powerful algorithms and optimizations working in modern software to make the slick graphics we now take for granted.

In an ideal world, every piece of software would be crafted to perfection, and would ship as a perfectly secure, extremely small chunk of code that runs blazingly fast because of the thousands of meticulous assembly-level optimizations that were performed. Reality falls short. But, on the other hand, our modern computers are really quite functional and fast. So I would say we should keep putting pressure on vendors to ship faster software, to the extent that we notice the slowness and it bothers us... but we should also acknowledge the real effort that is going into optimization all the time.

Actually (I have been running minefield since beta4):
* several of them at least were actual full browser crashes
* others were partial crashes (eg youtube stopped working for a few days in there because the flash plugin kept crashing)
* odd bugs like the addon bar disappearing (and without it there was no way to get to some extensions)
* bad UX in the panorama functionality (you could close panorama and lose all of the tabs you had open)
* app tabs were (and might still be, I haven't verified it yet) loading the page that they saw out of cache instead of online (resulting in when /. is an app tab me seeing the stories from weeks ago every time the browser is restarted)

agreed. these are serious bugs. although it is surprising that so many crash bugs have been fixed only in the 8th beta, but okay.

@2: Bull. The JM engine (JM+TM actually) is only currently beaten by the last few revisions of the v8 engine trunk repository, and only in the v8-bench tests (which feature very repeated tests that are benefited most by the v8 optimization set, which progressively further optimizes as lines of code are repeated): http://www.arewefastyet.com/awfy2.php [arewefastyet.com]; the IE9 beta engine doesn't actually appear to be any faster than the IE8 engine, but it does have some new dead code matching algorithms so that it seems faster on the benchmarks (that is to say it looks much faster on sunspider because a lot of that code never even gets run due to it being recognized as dead code, but on a site with heavy js usage the changes are insignificant).

you are saying that sunspider test results are bull. that's a new one, because i thought everyone considered that to be a real test of js performance. the whole reason why chrome is considered to be fast is that it scores way ahead on sunspider and sunspider-like tests. i find firefox 3.6 to have the same load times as chrome on almost every page. and then there are some pages (like slashdot discussions with >1000 comments) that load and scroll much faster on firefox 3.6 than chrome. so, if you disregard sunspider scores then you can't compare js performance objectively at all.

@3: Perhaps I don't understand what is so great here. Could someone enlighten me as to why we should care (as users and as web developers) about what particular windows specific hardware acceleration tech is being used?

its important because windows users are the people firefox owes its success to. the only way for firefox to continue its success is to keep its userbase happy, to provide them with a browser that better utilizes their hardware. in fact i think that mozilla knows this. that is why they've let firefox on linux stagnate. imo on linux, chromium is clearly miles ahead of firefox. on windows, firefox continues to be the browser of choice for me.

Actual new features that matter IMO in ff4:
.
.
.
multitouch api
.
. .

multi-touch apis exist only on windows 7. so firefox supports multi-touch only on windows 7. when you acted all arrogant about direct2d support saying you don't care about windows specific improvements, how could you point out to me a feature that is even more hardware and software specific? that stinks of double standards and just a compulsive need to defend firefox without thinking about the matter.
i use firefox as my main and only browser, even on linux where i find it bloated and slow compared to other options. but i have the ability to identify major shortcomings in the development of ff4, without fanboyism clouding my judgment.

Actually (I have been running minefield since beta4):
* several of them at least were actual full browser crashes
* others were partial crashes (eg youtube stopped working for a few days in there because the flash plugin kept crashing)
* odd bugs like the addon bar disappearing (and without it there was no way to get to some extensions)
* bad UX in the panorama functionality (you could close panorama and lose all of the tabs you had open)
* app tabs were (and might still be, I haven't verified it yet) loading the page that they saw out of cache instead of online (resulting in when /. is an app tab me seeing the stories from weeks ago every time the browser is restarted)

On your "points":
@1: while this is true, the new ui is more consistent from a themer's perspective and so this is easier to do

@2: Bull. The JM engine (JM+TM actually) is only currently beaten by the last few revisions of the v8 engine trunk repository, and only in the v8-bench tests (which feature very repeated tests that are benefited most by the v8 optimization set, which progressively further optimizes as lines of code are repeated): http://www.arewefastyet.com/awfy2.php; the IE9 beta engine doesn't actually appear to be any faster than the IE8 engine, but it does have some new dead code matching algorithms so that it seems faster on the benchmarks (that is to say it looks much faster on sunspider because a lot of that code never even gets run due to it being recognized as dead code, but on a site with heavy js usage the changes are insignificant).

@3: Perhaps I don't understand what is so great here. Could someone enlighten me as to why we should care (as users and as web developers) about what particular windows specific hardware acceleration tech is being used?

Actual new features that matter IMO in ff4:
1. JM engine
2. css border radius (proper support in all browsers will affect page sizes on a significant part of the internet)
3. css background image options (background-clip, background-origin, background-size)
4. css calc() function
5. html5 form elements
6. session history management (history.pushState, ...)
7. indexedDb
8. shipping sync with ff4
9. multitouch api
10. HSTS
11. JS typed arrays
12. considerable refactoring and deprecated code removal from Gecko (which will allow future development to happen faster)

While this beta is indeed far better than the last one, there still are some problems that need to be ironed out before it is ready for everyone. It still has some teething issues in the UI that take some getting used to (the status bar is gone, hyperlinks show the new url in the awesomebar, the context menu items for open in new tab and open in new window have swapped, etc.). I believe some of these are still changing. There are still 180+ bugs targeting ff4 and the underlying gecko 2.0 infrastructure (note ff4 is using a major upgrade of the underlying engine which it hasn't done a major upgrade since before ff1):

https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&target_milestone=Firefox%204.0b9&target_milestone=Firefox%204.0&target_milestone=mozilla2.0b9&target_milestone=mozilla2.0&product=Core&product=Firefox

Are we fast yet.com shows the measurements used by the Mozilla Javascript development team, comparing performance of ff4 to chrome/v8 and safari/nitro using both the sunspider (Mozilla) and v8bench (Google) test suites. LOTS of movement in Firefox over the past few months, including the apparent surpassing of Safari's Nitro engine in both tests and even beating Chrome's V8 in the Mozilla test suite.

This boost is likely due in part to the recently added hardware acceleration. This is listed as supported on all major operating systems (see the Firefox 4 Beta Technology page).

This is what the mozilla guys were talking about earlier this year. It is also why they came up with kraken. They were starting to see all of the browser 'speedups' becoming quite negligible on v8 and sunspider and flat lining. Also those particular bench marks are really meant to show off webkit and chrome. Mozilla came up with a benchmark of where they think the web is going. You will see a few more benchmarks suits before this is done.

But yes if you go from 2ms to 1ms http://arewefastyet.com/individual.php which you can see in some of the benchmarks. It would be a 100% improvement.

It really is a fairly mixed bag of who is faster. As what Mozilla also found was that some parts of the tests are weighted more than others.

But good on chrome for making the bar higher.

I think one of the reasons Chrome is affecting Firefox is the "Shiny new toy syndrome" and FF lack of willingness to support business needs.
If using Chrome becomes as "cool" as it was when Firefox started, then Firefox will be in trouble.

On the business needs side, Firefox is still stalling on:
-an official MSI package for Windows platform (BTW: If FF MSI cannot auto-update, corps will love it more. It's a control thing...)
-official, built-in, GPO support
-official, built-in automated add-on installation

On the JavaScript side, however, FF is doing pretty good lately: http://arewefastyet.com/

That's an oooold image.
Try posting a more up to date one. Firefox is now the fastest at Sunspider on x86 and faster than Chrome on x64.

http://arewefastyet.com/

Then of course there is Kraken...
http://m8y.org/tmp/kraken.xhtml

The problem with Sunspider, and this isn't unique to Firefox, is the shortness of the benchmarks. This does penalise Firefox at bit more which pays up front in tracing a bit for gains on more complex code later. It also encourages optimising for the harness and not the test.

Kraken and v8bench are still good tests. Oh, and just to be clear, IE9pp6 does a darn good job.

Check out its performance on this checkers AI.

http://www.bailopan.net/blog/?p=822

If you look at the graph you see this was coming for a long while now, the x64 version will also be fastest in a short while (presumably second to Opera - I don't know their x64 speed - but on windows Firefox x64 would be #1).

This is a great achievement from the development team who consistently improved the performance from 'quite bad' to 'competetively fast', so kudos to the developers. Please don't stop now, it seems you can still stretch performance quite a bit...

the result of this select query is .... (insert beavis voice from B+B) "uh uhuh huh chrome runs javascript 10 ms faster huh huhuhuh"

Chrome used to be faster, but isn't anymore. Firefox 4 beats Chrome on the Kraken and SunSpider benchmarks. See Mozilla's http://arewefastyet.com for some charts. Firefox 4 doesn't yet beat Chrome on Google's own V8 benchmark. I imagine Firefox 4 will close the gap to Chrome a bit more on V8 before it is released.

According to http://www.arewefastyet.com/, they're beating Chrome in Sunspider. That, plus their graphically accelerated rendering + compositing makes their Windows builds quite speedy.

But Google doesn't care if people use Chrome. It's free, and doesn't include any ads (and however much it tracks you, I doubt they make much money from that alone). Much like Mozilla, they released Chrome in order to drive browsers forwards. Crucially, Google want faster Javascript engines. And Firefox has risen to the bait.

There are several things wrong here:

1) Spidermonkey still compiles the AST to bytecode.
2) An assembler does just that: assembles. This means a 1-1 mapping of some other sort of
        representation of the exact machine instructions you want into actual bits in memory.
        There are no smarts here and no optimization going on; the only question is how fast
        you generate those bits in memory; an ideal assembler does this as fast as possible
        and without using too much memory. Now you have to generate assembly (or whatever
        representation the assembler takes as input) for it to assemble. That's the job of
        the compiler. JaegerMonkey takes the bytecode generated in step 1 and compiles it,
        passing the output to the assembler borrowed from Nitro. This compilation step is
        where (some of) the optimization takes place, and this is not code shared with Nitro.
3) Tracemonkey is most certainly useful for Sunspider; just not as useful as for other
        things. See, for example, http://arewefastyet.com/?machine=6 where the purple line is
        below the black one solely because of Tracemonkey. Alernately, see
        https://bug580468.bugzilla.mozilla.org/attachment.cgi?id=482609 where you can see the
        scores on each sunspider subtest as of a week or so ago; the -m column is JaegerMonkey
        without Tracemonkey, -j is Tracemonkey without Jaegermonkey, and -mjp is what's
        actually being used now (a combination of the two, with some smarts about deciding
        when to use which one).
4) The goal of Kraken is in fact to include anticipated use cases. If you know
        anticipated use cases it doesn't include, I'm sure Rob Sayre would love to know what
        they are.

Jesus guys, can't you just congratulate the Firefox devs on the great job they're doing? Just look at the rate of improvement over the past few months and give the JaegerMonkey/TraceMonkey guys kudos for a really impressive job of software engineering. Have a look at David Mandelin's recent post to get an idea of how much work and planning has gone into this project.

from http://arewefastyet.com/faq.html:

"3. Why isn't Opera/IE/something here?
Right now, the performance tests are run on a Mac, which means no IE. Also the tests rely on a "shell" JS engine that runs in a command line. It doesn't test browsers. We'll change that, eventually."

And how javascript speed of firefox has improved.

And it looks like optimization work is still very much ongoing. http://arewefastyet.com/

On Mozilla's arewefastyet.com they've put up some nice comparison charts of the Kraken benchmark in various browsers.

On Mozilla's arewefastyet.com they've put up some nice comparison charts of the Kraken benchmark in various browsers.

I'm not sure it's really a case of Mozilla trying to trick anyone... after all, they happily (well, probably not _happily_) admit that they aren'tfastyet

Read the FAQ, #8.
It's slower now, but once it's been optimized for 64-bit it'll be as fast, if not faster. Meanwhile, your machine is probably faster in other ways.

Nitro is faster running on x86_64. Bear in mind that http://arewefastyet.com/ does not show browser based comparisons. It runs the JavaScript engines independent of the browser.

According to http://arewefastyet.com/ they have come from being 2x-3x slower than Safari and Chrome a few months ago (v8/sunspider benchmarks) to being within a few percent to 25% of Safari and Chrome, depending on the benchmark.

I think that's pretty impressive - it basically puts them in the right ball game now, and narrows the performance gap to the barely noticeable range for most practical purposes.

Check out http://arewefastyet.com/ to see the speeds of several JavaScript engines compared to Mozilla's.

http://arewefastyet.com/

I'll just leave this here...

In the old days, JavaScript was interpreted. This means that the JavaScript engine is evaluating the program as it runs, instead of the CPU evaluating the program. This is what the Firefox SpiderMonkey engine does and it is slow.

When Chrome was released and there was a push to make things faster, Mozilla wrote an engine called TraceMonkey. This engine supports tracing jit, which is to say that the engine watches what javascript code gets executed (the tracing part) and uses that to produce optimised code that the CPU will execute (the jit -- or just-in-time compilation -- part).

Chrome's V8 engine, Apple's Nitro engine and others use what is called method jit. This means that the javascript code for a method (function) is compiled to code the CPU can execute when that method is called.

Mozilla are currently working on a similar method jit engine called JaegerMonkey. This engine is taking the nitro assembler (the code that generates the CPU instructions) and writing everything else on top of this. In addition, they are also taking the Yarr! regular expression engine that IIR, Chrome is using to speed up their regular expression handling.

Mozilla are looking to blend the method jit and tracing jit together -- hence the "one generation ahead" comment.

Mozilla are also optimising various javascript calls (a contrived example would be replacing calls to Math.sin with the sin CPU instruction) to provide "fast paths" that speed up code that uses those calls.

http://arewefastyet.com/ shows the performance of these over time.

You mean, in several months Mozilla will be approaching the level that Google is at now. It's become pretty clear that Google is able to develop Chrome much faster than Mozilla is able to develop Firefox.

No. I mean in a couple of months Mozilla's JavaScript engine will likely match Google's. In several months Mozilla's engine may have surpassed Google's.

Also, Opera is faster than Mozilla as well, I'd like to see it included on that chart to compare with the others. Maybe even IE9, if it doesn't skew the Y-scale too much.

Read the FAQ.