Slashdot Mirror
Firefox Faster In Wine Than Native
An anonymous reader writes "Tuxradar did some benchmarks comparing Firefox's Windows and Linux JavaScript performance. 'We did some simple JavaScript benchmarks of Firefox 3.0 using Windows and Linux to see how it performed across the platforms — and the results are pretty bleak for Linux.' Later on, they tried Wine. 'The end result: Firefox from Mozilla or from Fedora has almost nil speed difference, and Firefox running on Wine is faster than native Firefox.'"
Check the doco
Firefox 3.0 built for Windows was PGOed (Profile Guided Optimisation)
PGO was not yet enabled for linux builds
Try a newer build.
FAIL
The Singularity is closer than you think
Quant
By default Firefox for Linux uses shared system libraries rather than statically linking them altogether as the Windows version does. That's bound to have an impact on performance because code and data pages will be all over the place. Type "about:buildconfig" into the browser and it will tell you its build settings.
Profile Guided Optimization (PGO) is where you compile a special "recording" build of a program, then run it just using your core feature set and "ordinary" tasks. You don't perform a full test, or click on all the options or settings, you just go through normal end-user use cases. The special build then records a "profile" of your typical usage. You then feed the source code plus the profile back into the build process to build your production code.
The idea is for the linker to identify the hot spots in memory, and group as many of them together as possible so they live on common pages. This helps keep those pages from being swapped out of memory to disk due to disuse, which greatly reduces the amount of thrashing your end users will see during normal use. Less thrashing == improved performance.
John
Oops, sorry, I didn't answer your "why not?" question directly. My guess is that because it takes a fair amount of additional work to create the profile after each build, the step may have been skipped by the Linux build team. As far as I know, profiles are unique to each build: you can't create a profile under the Windows image and reuse it on the Mac or Linux builds.
That's just a guess, though, I could certainly be wrong about that. I'm sure a PGO expert or perhaps a member of the Firefox build team will chime in here soon to correct me if I am.
John
That's way off base. There are no context switches when making a library call. Context switches occur when you ask the kernel to do something by making a syscall. So memcpy or memcmp don't incur a context switch. Nor do fopen or fread in and of themselves cause context switches. But one will occur when the underlying open and read calls are made.
What's really needed here is a profiler to find where the code is spending the bulk of its time. My guess is that it's a compiler issue. And other comments about the windows build using profile guided optimization tell me my guess is probably right.
You obviously have no idea what a context switch is.
A context switch happens when the scheduler stops one process/thread and gives the CPU to a different one. This has nothing to do with cross-library calls.
sig intentionally left blank
PGO in GCC: http://gcc.gnu.org/install/build.html#TOC4
Colorless green Cthulhu waits dreaming furiously.
It doesn't really have to do with X or Firefox so much as the interaction between X and Firefox. Composition effects and pixmap caching at the two prime issues.
Composition is when you draw an image that blends with what is already on the screen. Right now, a lot of the Xorg code that accelerates composited effects is unfinished. In particular, rendering composited text is painful. The brute force solution of blending with what is on-screen is awful, because reading from video ram is very, very expensive. So optimizing this is pretty non-trivial since the optimization must be that you don't look at what you need to blend with! Progress is happening though.
Pixmaps are used to store images in the X server. Firefox, to get the rendering effects it wants, often uses large pixmaps for application elements. Large pixmaps can cause memory fragmentation issues, making later allocations harder, causing performance to slowly decline over time. Again, this is something being worked on, but in this case, the client is really not behaving very nicely.
Like I said, progress is being made on these fronts - Xorg's xserver 1.5 and 1.6 are supposed to have some good acceleration improvements. There's been work on a much improved glyph cache for EXA accelerated fonts. I haven't run any of these, since my distro currently ships 1.4, and I don't really plan on upgrading until Debian does. But since it's a pain point for me, and I read the development mailing list, I thought I'd share.