Firefox Faster In Wine Than Native 493
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.'"
Why not? (Score:5, Interesting)
Re:Really a surprise? (Score:1, Interesting)
And Linux is not a monolithic do-it-all library architecture?
And UNIX is easier to bug fix? Huh? Come on this is fairy tale stuff...
What they are talking about here is that a Windows application using Wine is faster than a UNIX application on UNIX.
I also would believe your argument if we were talking about a UNIX app built specifically for UNIX and Windows app built specifically for Windows. But we are not. We are talking about Firefox...
My guess is like a poster up above who said that optimization flags were used on Windows, and not on the Linux native build.
Firefox is slow on Linux in general (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.
VM speed (Score:1, Interesting)
Running firefox in TinyXP in Virtualbox is faster then native on my Ubuntu......
PS. My captcha is 'rejoice'
Re:3.1 Please! (Score:2, Interesting)
http://slashdot.org/comments.pl?sid=1126185&cid=26840435 [slashdot.org]
See here - did a test on sucky slashdot 2.0
Still sucks
Re:Firefox is slow on Linux in general (Score:1, Interesting)
Though Not Dramatic, Interesting Nonetheless (Score:5, Interesting)
However, the results are not that dramatic. I'd be curious to see a few things, including how Native FF runs in KDE with the Gnome libraries loading up. (I run KDE.)
Also of note - I've posted before on lists that "starting" Word 2003 takes about half the time as it does to "start" OpenOffice 2.x on my distribution. I run CrossoverOffice and have Office 2003 loaded. My guess is that there may be something in Wine that optimizes these processes.
Re:Firefox is slow on Linux in general (Score:5, Interesting)
To hell with faster, what about more STABLE? (Score:1, Interesting)
Firefox is way more stable in my experience under MS Windows (and maybe WINE?) than under LINUX/X.
Admittedly I'm probably more of a 'power user' than most, but the thing that kills me about LINUX Firefox
is its GROSS instability under heavy load (e.g. problematic on both Fedora and Ubuntu 64 bit editions anyway).
It takes anywhere from a few minutes to a couple of hours of ordinary use in order for it to just crash and close down on me with no core dump.
This is on systems with 8GB RAM (so it is not a resource shortage), not using FLASH or similar plugins, and not always / generally using proprietary ATI/NVIDIA video drivers. Admittedly this often occurs with a high number of windows/tabs open (e.g. 85 windows, 500 tabs) -- just because that's a normal evolution of me leaving stuff open instead of closing them. However I've had it crash similarly frequently when only a few dozen windows/tabs are open, so it isn't strictly a super heavy load issue. Generally the crash is accompanied by some X windows system error, BadIDChoice or such. Here's a ~ 2 year old Ubuntu "confirmed" bug report listing very similar crash problems, though the exact X error seems like it could be a bit different here:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/97492 [launchpad.net]
I just don't get their LINUX quality control, this happens so repeatedly over numerous 3.X versions of FF that I must assume that an automatic test script that repeatedly opened / closed a few hundred windows mocking normal usage would repeatedly trigger this, yet after apparently a couple of years of the problem being unresolved I still see no diagnosis / workaround / fix.
This just doesn't happen under MS Windows, though I tend to load down XP / Vista SLIGHTLY less with open tabs / windows than on LINUX, but on LINUX I can run FF for hours or days if I'm lucky. On MS Windows I can run it for days or weeks, so this is rather embarrassing / frustrating since in all other day to day use respects LINUX tends to be equal or superior to MS Windows in stability / functionality.
No chrome (yuck), super unstable firefox, konqueror just doesn't compare, opera I'm not a fan of == unhappy LINUX browsing.
One thing Chrome got right is one system process per window, at least a single error doesn't take down HUNDREDS of open browser windows. Even better would be true error recovery so that any error would just cause the affected threads / tabs to be reloaded with no loss of context and not having the whole browser crash. The automatic crashed session recovery is about the only thing that has kept me using FF on LINUX, though it sucks to wait like 20 minutes for your pages to reload, and then never perfectly (lost form data / buggy reload processes / whatever).
Re:Why not? (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.
Re:Why not? (Score:4, Interesting)
I wonder if they could include this profiling in an opt-in user service. Whereby large amounts of profile data could be collected from the users and build a better aggregate profile. Or perhaps this would provide too little return on investment as the new data would not significantly improve on the existing profile and would only add to the complexity of the software.
multiple reasons (Score:1, Interesting)
In my experience this is for multiple reasons gnome, compiz, pango, flash... Try running it on a gentoo system compiled without pango and on kde. Probably will be faster and more responsive
Recompile please (Score:3, Interesting)
Re:Not suprised (Score:3, Interesting)
The native MS compiler is actually pretty dang good. It out compiles gcc any day of the week. MS need only worry about optimization details for a single architecture and platform. The GCC guys on the other hand have to optimize for tons of different chips, variants, and platforms, and as such are much more limited in what they can do. Furthermore, its is very likely the MS compiler supports many optimizations which GCC simply doesn't even support.
So its really not fair to say they created a half-assed version for Linux. There are many potential reasons why performance can greatly vary between platforms - especially if different compilers are used to create the builds.
Now here is some food for thought. Considering MS has a vastly superior compiler which commonly generates code 20%-50% faster, and in some corner cases even more than GCC, now imagine how poorly much of their code is written such that Linux with such a performance penalty, due to its native compiler, commonly out performs Windows. Hmmmm....
Re:Not just Wine (Score:3, Interesting)
I think it's mostly that Firefox on Linux tries to use features of the graphics driver that aren't properly accelerated. This seems particularly true on newer nVidia cards - a GeForce 9 series card is much slower than a GeForce 7 series card, even with the latest drivers.
I've actually had the Linux version of Firefox performing better inside a VM than natively, because in the VM it has no accelerated drivers, and is forced to do everything in software. It turns out that, in spite of the VM overhead, software rendering everything and then just blitting the entire thing in one go using an accelerated driver is faster than using the accelerated driver to draw the thing in the first place.
I guess that's why Mac OS X doesn't use hardware accelerated rendering, except for compositing windows. Firefox is plenty fast on Mac OS X, although still noticeably slower than on Windows.
Re:Really a surprise? (Score:4, Interesting)
I'm not sure what the specifics are causing it, but I can honestly say that native Firefox on my Linux (Mint 6) system just blows. I have no idea just what they got wrong, but compared to my Windows systems (Vista on laptop, XP on my home desktop and work desktop), or my Mac systems, it just blows. Firefox on my 500mhz G4 Mac with 512MB of RAM is literally a whole different experience compared to Firefox on a 2.8Ghz Celeron Linux system with 2GB of RAM (I've also testing similiar results on my MythTV box which is a Sempron 3400 w/ 1GB RAM, and my old Linux machine which was an Athlon XP2100 w/ 1.5GB).
If I'm working slow - casually browsing the web, then I can't notice. Thing is I tend to crank open tons of tabs and flip between then when I'm web surfing. At work now (where I open less than at home), and having been here 15 minutes I count 12 tabs open in this browser session. At home I can easily have 75 or more open at once. Usually when flipping between them I'm a very fast clicker, and there is a most definate noticeable pause in the rendering as Firefox on Linux switches between tabs or closes/launches one compared to the other platforms. In general the pages themselves, when network bandwidth isn't the bottleneck, also render a tad slower and more "klunky" (ie, for fractions of a second I can see things appear in one spot and then quickly rearrange to their final positions, where on the other platforms I would have seen far more items just appear in their final location).
Even though it still doesn't match regular Firefox on the other platforms, I've taken lately to using Epiphany. While it has it's own issues, it still does have a slight speed edge over FF so I continue to use it for now.
Truthfully, if Linux could FINALLY ditch the inherent "slow" feel to most of it's apps (which I think it really more an issue with xorg and the GUI toolkits more than "Linux", though I'm speaking as an overall platform not a kernel here), then I think it'd pickup a lot of new users, and some part-time users might well become full time.
Re:You not thinking Milti-Core. (Score:5, Interesting)
Laptops in particular often have slow hard drives. Antivirus slows them further. You're probably waiting for the disk all the time.
It's often compounded in a business environment by other disk access apps (auditing etc).
I know on my laptop, lauching firefox involves McAfee scanning Firefox, then Centennial scanning Firefox, then McAfee scanning Centennial, then McAfee scanning Firefox again.
My biggest frustration w/ Linux (Score:3, Interesting)
But FF's crappy performance/speed/response on Linux just really really sucks.
I keep looking for a new browser, but Konq + multimedia = crashtastic, midori & kahazekhaze are too overall unstable, and Epiphany is just under-featured. Opera isn't FOSS (which slays me--I love Opera like a little girl loves ponies, but I've got a pretty strong ethical committment to FOSS).
There's always elinks ;).
68-104 (Score:2, Interesting)
Maybe you're just cursed (Score:3, Interesting)
I rebooted today after 42 days of uptime, and that includes 42 days of uptime of FF3 under Mandriva 2007.1. No crashes, not a one.
One thing I'd immediately observe, are you using a compositing window manager? Turn that crap off, nothing destabilizes X apps more than compiz and friends.
Other than that, I don't know, but your experience is totally opposite mine. Not only is FF3 adequately fast, it is perfectly stable. I can't say if it would be faster in windows or not because I don't HAVE windows and don't need it, but it is a perfectly fine browser as is.
Re:Firefox is slow on Linux in general (Score:2, Interesting)
... I'm using the proprietary ATI drivers on Linux, which should be pretty fast...
Wrong! The proprietary ATI driver sucks donkey balls! Two months ago I went from Nvidia 8600GT to ATI 4850HD (both pci-e) and I was astonished how bad were the drivers from ATI(with the nvidia card I used the proprietary driver too).
- no proper xv output. it doesn't sync the frames to vsync and there is horrible video tearing. The only solution to this was to enable vsync for OpenGL and use -vo gl with specific mplayer build 1.0_rc2_p28058-r1. Later builds were horribly slow with -vo gl and were unable to play even 720p video.
- horrible x11 performance. try some x11perf tests and compare the results. My card was 10-20 times slower than a low-end nvidia card.
- no support for the linux driver. End of discussion. You can "make suggestions how to improve it", but that's all.
As I only occasionally boot to windows to play games, choosing ati card was a huge mistake. On the next upgrade I'll go with nvidia again.
Re:Noticed this for a while now (Score:2, Interesting)
GTK+ is damned slow. The file manager, Nautilus, has nothing to do with GTK+. Compare a GTK+ v2.0 app to a GTK+ v1.0 app. The GTK+ v1.0 app is orders of magnitude faster.
Re:Why not? (Score:3, Interesting)
I'm posting this on a netbook, (asus aspire one) with Fedora 10, 1.5Gb of ram, and no swap.
Currently I have FireFox (plus real+flash plugins), gimp, aMSN (3 sessions, 2 with webcam) plus all the usual Gnome bits ruinning, and /proc/meminfo says just under 1/5th of the memory is active. I'm starting to wonder if swap is just another obsolete solution to a problem that no longer exists for most real-world users.
The only things I have seen using swap these days are clunky bloated Java webapps on our servers in the office. (Artifactory is particularly poor in this regard, how any piece of software can use so much resource while delivering so little functionality I just don't know).
Re:Why not? (Score:4, Interesting)
You are right that in desktop use scenario with over 1GB of RAM you will likely never use the swap.
If you run something very memory intensive like photo/video editing, VMware, etc. you may, but with today's standard RAM allotments most desktop users never touch swap in Linux.
So can you compile yourself? (Score:3, Interesting)
Can you compile Firefox & Ubuntu yourself and get better performance, then?
Re:Why not? (Score:3, Interesting)
So, logically static profiling plus dynamic profiling yields even better results, right? Java and similar languages do have a compiler you know :) But they can also do things that you cannot do in a purely static environment. For example, the hotspot VM can dynamically inline method calls that might end up being virtual and then un-unline them later if needed. Also, it's called "hot spot" because the point of the profiling is to spend the time where it's useful... not everywhere. And you can't necessarily divine statically where that will be. That's the whole point of the PGO pass the article discussed... you have to run the code to understand what is calling what and juggle resources accordingly. There is no simple static "best" answer. And so, again, this is where Java and similar languages have a performance advantage over purely static languages - they get the benefits of both static and dynamic analysis.
- Pat Niemeyer
Re:Why not? (Score:3, Interesting)
I just wanted to point out that statically compiled code with PGO is even more advantageous because your final version is optimized with the runtime information, but doesn't have profiling code built in (which the java version would). So once again, static languages win.
Sorry, just tired of this stupid slashdot meme.
Sluggish because of disk access (Score:3, Interesting)
This will go unnoticed, but what the heck.
I was able to greatly improve the reactivity of both firefox and opera by moving the cache onto tmpfs systems. Actually, I moved full rc directories (.opera and .mozilla) and just rsync them from time to time.
Caveat - I have a sort of an improvised SSD (using a CF card and an adapter), which is quite slow esp. for concurrent writes. But maybe this is why I noticed it at all. I don't understand why the browsers insist on writing tons of data onto the hard drive when there's plenty of perfectly good memory lying around.
Cheers,
j.