That's incredible. I would expect OS X to be a bit neglected, but I'm surprised that the Linux version has more complaints than the Windows version. You would expect that to be a popular platform for people who would develop Firefox.
Then again, perhaps Linux and OS X users are just more picky than Windows users.
As I understand it, the Firefox project was started explicitly to develop a better browser for Windows (as opposed to the main Mozilla project at the time, the cross-platform Mozilla Suite). The whole idea was to challenge Internet Explorer's hegemony, and Linux users were (obviously) incidental to that goal.
As far as I know, Windows is still the priority OS for Firefox. Certainly, for a long time Firefox's Javascript performance has been noticeably worse on Linux than on Windows. And the shiny new hardware-accelerated rendering in 4.0 is Windows-only. And let's not even start on Flash (not that the Firefox team can be blamed for that, but it's a part of the browser experience).
Is any JavaScript engine faster with GCC than with MSVC? Most of the difference I've observed has come down to compiler quality on 32-bit Intel systems. I don't think Linux vs Windows has much to do with JavaScript performance.
I have definitely perceived Firefox to be slower on Linux than on Windows, particularly with Javascript-heavy apps. (Moreso in the days of 3.0 admittedly - I barely use Windows now anyway so I can't compare.) I was also under the impression that this was a common and widespread perception.
I don't know exactly what's the cause of the slowness I perceive - whether it's the Javascript VM or the DOM implementation, or some interaction of those with something more plausibly platform-specific. I'm afraid I haven't tried recompiling Firefox with different compilers to test this!
Any browser will be affected by that JS issue. JavaScript VM code is largely identical across platforms. See this post by a member of the Chrome team [1].
Hardware accelerated rendering (accelerated layers) is in fact enabled by default on the Mac. Unfortunately, Mac OS X has no equivalent to Direct2D (that's enabled for production, that is). You can enable hardware accelerated layers on Linux via about:config; they work, but they're disabled by default due to frequent driver crashes. You do get something approximating Direct2D on Linux Firefox via XRender, if your graphics drivers support it.
[Disclosure: I work at Mozilla, and have been closely involved in the JS engine for some time.]
For a while (3.5 and 3.6, I think), Linux distributors shipped 64-bit builds of Firefox, which did not have JIT support. (Mozilla did not produce supported Linux-64 builds until 4.0.) Experimental Windows 64-bit builds had the same problem, but most people even on 64-bit Windows would use the 32-bit version. Linux distributors would also build Firefox to ease their package management, rather than to optimize startup speed, so again if using a distro Linux build you were in the penalty box.
MSVC also has PGO support which we still can't get working properly on gcc, and which used to make a very substantial difference in JS performance, and still makes a small one. Add to that the PIC register overhead, and that we had to compile with frame pointer on Linux for some time until we added CFI support to the crash reporting software, and there were lots of places where the toolchain just didn't keep up.
Animated performance tests are likely to be slower on Linux than on Windows due to graphics differences rather than the underlying JS performance. In fact, one of the ways that we generally tell if something is JS-related or not in initial triage is whether it's cross-platform or different on different OSes.
Windows is where most of our users are, but most of our developers are still on OS X I think. After that is probably Linux, but it's a close call. More are moving to Windows, mostly to be closer to the dominant user experience. Linux generally suffers most in the graphical department, due to the...variable quality of available drivers. compiz itself has an extensive blacklist of drivers, and that's coming from the distros themselves! I don't think anyone can reliably get Linux video driver bugs fixed, and we've been waging a battle against Linux graphics stack performance problems for some time ourselves.
(One major performance issue for us is theme drawing and using stock icons and doing other "be a good Linux desktop citizen" stuff. Chrome went the other way, doing their own thing and not having to load icons synchronously, or re-initialize the font system on startup, or do all form-widget drawing through gdk-indirection-slowtown. I think it's clear at this point that we erred in listening to what the Linux faithful told us they wanted, and we should have listened to our instincts.)
On Android our JS performance is pretty great, even though the native toolchain isn't exactly fantastic. That's probably the most important Linux platform in the world right now.
10 comments
[ 2.7 ms ] story [ 27.6 ms ] threadThen again, perhaps Linux and OS X users are just more picky than Windows users.
As an OS X fan I've got to say that's probably true.
As far as I know, Windows is still the priority OS for Firefox. Certainly, for a long time Firefox's Javascript performance has been noticeably worse on Linux than on Windows. And the shiny new hardware-accelerated rendering in 4.0 is Windows-only. And let's not even start on Flash (not that the Firefox team can be blamed for that, but it's a part of the browser experience).
Is any JavaScript engine faster with GCC than with MSVC? Most of the difference I've observed has come down to compiler quality on 32-bit Intel systems. I don't think Linux vs Windows has much to do with JavaScript performance.
I don't know exactly what's the cause of the slowness I perceive - whether it's the Javascript VM or the DOM implementation, or some interaction of those with something more plausibly platform-specific. I'm afraid I haven't tried recompiling Firefox with different compilers to test this!
Hardware accelerated rendering (accelerated layers) is in fact enabled by default on the Mac. Unfortunately, Mac OS X has no equivalent to Direct2D (that's enabled for production, that is). You can enable hardware accelerated layers on Linux via about:config; they work, but they're disabled by default due to frequent driver crashes. You do get something approximating Direct2D on Linux Firefox via XRender, if your graphics drivers support it.
[1]: http://neugierig.org/software/chromium/notes/2010/05/fast.ht...
For a while (3.5 and 3.6, I think), Linux distributors shipped 64-bit builds of Firefox, which did not have JIT support. (Mozilla did not produce supported Linux-64 builds until 4.0.) Experimental Windows 64-bit builds had the same problem, but most people even on 64-bit Windows would use the 32-bit version. Linux distributors would also build Firefox to ease their package management, rather than to optimize startup speed, so again if using a distro Linux build you were in the penalty box.
MSVC also has PGO support which we still can't get working properly on gcc, and which used to make a very substantial difference in JS performance, and still makes a small one. Add to that the PIC register overhead, and that we had to compile with frame pointer on Linux for some time until we added CFI support to the crash reporting software, and there were lots of places where the toolchain just didn't keep up.
Animated performance tests are likely to be slower on Linux than on Windows due to graphics differences rather than the underlying JS performance. In fact, one of the ways that we generally tell if something is JS-related or not in initial triage is whether it's cross-platform or different on different OSes.
Windows is where most of our users are, but most of our developers are still on OS X I think. After that is probably Linux, but it's a close call. More are moving to Windows, mostly to be closer to the dominant user experience. Linux generally suffers most in the graphical department, due to the...variable quality of available drivers. compiz itself has an extensive blacklist of drivers, and that's coming from the distros themselves! I don't think anyone can reliably get Linux video driver bugs fixed, and we've been waging a battle against Linux graphics stack performance problems for some time ourselves.
(One major performance issue for us is theme drawing and using stock icons and doing other "be a good Linux desktop citizen" stuff. Chrome went the other way, doing their own thing and not having to load icons synchronously, or re-initialize the font system on startup, or do all form-widget drawing through gdk-indirection-slowtown. I think it's clear at this point that we erred in listening to what the Linux faithful told us they wanted, and we should have listened to our instincts.)
On Android our JS performance is pretty great, even though the native toolchain isn't exactly fantastic. That's probably the most important Linux platform in the world right now.
":( incompatible with farmville toolbar"