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