Slashdot Mirror

← Back to Stories (view on slashdot.org)

Firefox Faster In Wine Than Native

Posted by timothy on from the that-sounds-hard-to-swallow dept.

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.'"

18 of 493 comments (clear)

  1. Dear losers by tqft · · Score: 5, Informative

    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
    1. Re:Dear losers by Anonymous Coward · · Score: 5, Funny

      You should test it for yourself - benchmark which setup loads the fucking article fastest and let us know how that turns out.

  2. First post... by Anonymous Coward · · Score: 5, Funny

    except I'm using Linux

  3. about:buildconfig by DrXym · · Score: 5, Informative

    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.

  4. Re:How fast do we need? by RiotingPacifist · · Score: 5, Funny

    hey i want the page render before i even click the link (possibly using thiotimoline, but i don't care about specifics), until the browser does that i will never be happy!

    --
    IranAir Flight 655 never forget!
  5. Firefox is slow on Linux in general by Teckla · · Score: 5, Interesting

    I dual boot between Windows XP and Ubuntu GNU/Linux (of the Intrepid Ibex flavor).

    Firefox is slow on Linux in general. Page Up, Page Down, Arrow Up, Arrow Down, Ctrl+Plus and Ctrl+Minus (to increase and decrease the font size)...all of these things are instantaneous on Windows XP, but there's a noticeable lag on Linux.

    I'm not sure what the problem is. I'm using the proprietary ATI drivers on Linux, which should be pretty fast. And my machine is old enough that all the kinks should have been worked out of the Linux drivers for my hardware.

    1. Re:Firefox is slow on Linux in general by Anonymous Coward · · Score: 5, Informative

      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.

  6. Re:Why not? by plover · · Score: 5, Informative

    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
  7. Re:Really a surprise? by clickclickdrone · · Score: 5, Insightful

    >But are we really going to try to maximize speed over durability?
    I was taught very early in my IT career that there are 3 considerations on any project.
    1. It can be cheap
    2. It can be fast
    3. It can be reliable.
    Now go and pick 2 out of 3.

    --
    I want a list of atrocities done in your name - Recoil
  8. Re:Why not? by plover · · Score: 5, Informative

    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
  9. Re:Really a surprise? by Jimithing+DMB · · Score: 5, Informative

    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.

  10. Re:Really a surprise? by SCHecklerX · · Score: 5, Funny

    Actually, I think it's "Good, Fast, Cheap. Pick 2". And for online dating, it seems to be "Attractive, Intelligent, Sane. Pick 2".

  11. I know that Swiftfox has not been making people by aussersterne · · Score: 5, Insightful

    happy for non-technical reasons, but I continue to use Swiftfox on Linux because it is so damned much faster than Fedora's Firefox build.

    I know that there is a CPU optimization difference, but I haven't looked into other differences. Someone who has looked at the buildconfig for both and/or who knows about the build processes and configurations of both: is the reason for the slowness in the comparison referenced in this post related at all to something that Swiftfox is fixing?

    --
    STOP . AMERICA . NOW
  12. Re:Really a surprise? by rkit · · Score: 5, Informative

    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
  13. Re:Why not? by gzipped_tar · · Score: 5, Informative

    PGO in GCC: http://gcc.gnu.org/install/build.html#TOC4

    --
    Colorless green Cthulhu waits dreaming furiously.
  14. Re:Why not? by somenickname · · Score: 5, Interesting

    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.

    You were correct until here. This isn't PGO's primary purpose. It may do this to prevent TLB misses but, certainly not to lessen the impact of swapping (which for an average desktop linux user is almost non-existent). Optimization is about making decisions about what is likely to produce the fastest code. If the compiler knows how the code is going to be used, it can make better decisions.

  15. Re:How fast do we need? by Hatta · · Score: 5, Insightful

    Have you visited Slashdot.org with javascript on in Firefox recently? It stalls for a couple seconds while formatting those god awful tags.

    I guess it's easier for Taco to wait for Firefox to get faster, instead of writing decent code to begin with.

    --
    Give me Classic Slashdot or give me death!
  16. Re:Really a surprise? by DarthVain · · Score: 5, Funny

    Attractive and Intelligent works for me! Just don't sleep with her, and by sleep I mean fall asleep. Also hide all knives and scissors.