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.'"
Dear losers (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
Why not? (Score:5, Interesting)
Re: (Score:3, Informative)
http://en.wikipedia.org/wiki/Profile-guided_optimization [wikipedia.org]
Re:Why not? (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.
Re:Why not? (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.
Re:Why not? (Score:4, Insightful)
Re: (Score:2)
This has nothing to do with your firefox user profile.
Re:Why not? (Score:5, Informative)
Re: (Score:3, Informative)
Re:Why not? (Score:4, Insightful)
Re: (Score:2)
It's also theoretically possible for the compiler to use PGO, if there are safe optimizations that are too slow to use normally. I don't know whether any such optimizations exist.
Re:Why not? (Score:5, Informative)
Inlining everything == Bad (Score:3, Informative)
cache misses are __WAY__ more expensive than subroutine calls.
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:5, Insightful)
Just wanted to point out that this is the advantage that Java and other runtime profiling languages have over purely statically compiled code. The more information you have the more you can do.
Re: (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.
Re: (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 necessar
Re:Why not? (Score:5, Informative)
I think that is why GP said the impact of swapping "for an average desktop linux user is almost non-existent" ...because for an average desktop linux user swapping is almost non-existent.
I've run Linux machines (for short periods of time, with no more than normal desktop use loads) without any swap, and they work fine... but when you hit that wall of running out of physical RAM you'll feel it a lot more without swap than you would with a swap file/partition.
Windows on the other hand seems to want to use several hundred megs of swap whether it needs it or not.
Re: (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
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.
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.
Re: (Score:3, Insightful)
Re:Dear losers (Score:4, Insightful)
It may also have something to do with firefox on windows being built with MSVC, which generally produces faster code than gcc...
I believe windows firefox is also compiled for i686 or even pentium3, whereas on linux it's typically compiled for i386.
What would be interesting to see, is optimized builds of firefox compiled with various compilers and options, i'm pretty sure a gentoo box with firefox compiled by intel's compiler could comfortably beat the windows binaries...
Re:Dear losers (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.
First post... (Score:5, Funny)
However... (Score:5, Informative)
On the flip side, the pop-unders I get from my local newspaper's site under Firefox don't happen under Linux, only Windows.
*shrug* (Score:2, Insightful)
What I "lose" in javascript performance, I think I more than make up for in not wasting any cpu cycles on anti-virus crud.
I'm not at all sure how relevant these synthetic tests are. I use Ubuntu 8.10 on a 2 year old laptop and it honestly feels snappier now than it did when it was running XP. Maybe some things are slower and some things are faster. Beats me, as I'm too busy actually using it for real work to be bothered benchmarking it. But on the whole, it certainly "feels faster" now.
Best,
You not thinking Milti-Core. (Score:2)
In theory if you have the web browser the performance of the Anti-Virus running on different CPU so you are not getting any real speed savings. So if you have a slow web browser you still have a slow web browser with or without Anti-Virus. (Yes I know it is more complex then that, wait time for sharing IO, Joining Busses etc...)
Re: (Score:2)
In theory if you have the web browser the performance of the Anti-Virus running on different CPU so you are not getting any real speed savings.
Well there's your problem: your theory seems to assume that AV software doesn't always expand to take up all the CPU power available to it. ;)
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.
Re:*shrug* RTFS? (Score:2)
What I "lose" in javascript performance, I think I more than make up for in not wasting any cpu cycles on anti-virus crud.
Firefox in _Wine_, not Win. TFA was still using Linux, but was using Wine on top of Linux, with Windows version of FF.
Re: (Score:3, Funny)
3.1 Please! (Score:2)
More interested in Firefox 3.1 JavaScript speed!
Re: (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
Not suprised (Score:4, Insightful)
Mozilla created Firefox for Windows, and then they made a half-assed version for Linux. I'm not really surprised that the Windows version runs faster. Wine usually runs programs at about the same speed as the Windows version. Sometimes a little more, sometimes a little less.
I don't see how this "looks bleak for Linux." Damn trolls.
Re: (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 versi
Re:Not suprised (Score:4, Informative)
Your little theory is disproved by this chart:
http://www.agner.org/optimize/optimizing_cpp.pdf [agner.org]
And scroll down to page 68. GCC does everything MSVC does, and more. The chart says that GCC doesn't implement PGO yet, but currently it does.
The cause of Firefox underperforming on Linux is most certainly not using PGO in Linux builds, which is a distribution issue more than a Firefox issue.
Well, the chart's wrong. (Score:5, Insightful)
GCC does everything MSVC does, and more
This is simply not true. From the chart, Microsoft has Fastcall, disabling exception handling, simple member functions, and GCC does not. Additionally, the chart also incorrectly states that Microsoft does not have an option for fast but imprecise floating point. It does.
On the flipside, MSVC++ has whole program optimization, which GNU calls LTO. LTO doesn't exist for GNU yet. See here:
http://gcc.gnu.org/wiki/LinkTimeOptimization [gnu.org]
Scroll down and read. Pretty much, LTO looks to require a new C/C++ parser. That's not going to happen overnight.
Rats! (Score:2)
If Firefox ran faster in Wine than in native Windows, that would be great news. As it is, it's undoubtedly because Firefox's code is optimized for Windows, rather than Linux.
Re:Rats! (Score:5, Insightful)
If Firefox ran faster in Wine than in native Windows, that would be great news. As it is, it's undoubtedly because Firefox's code is optimized for Windows, rather than Linux.
If it runs faster in Wine than either native on Windows or native on Linux, that'd be really cool. Or funny. Or sad. I'm not yet sure which.
How fast do we need? (Score:5, Informative)
Seriously, how fast does a web browser *need* to be? I've never been using Firefox on Linux and thought to myself that it was prohibitively or even annoyingly slow.
Reading TFA, in most cases, the differences in times don't seem dramatic, either, so who really cares?
Re: (Score:2)
Re: (Score:3, Insightful)
All browsers are prohobitively slow at times. Not to mention their memory footprint.
Re:How fast do we need? (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!
Re: (Score:3, Funny)
For some reason they called those security issues.
People are never satisfied
Re: (Score:2)
Re: (Score:3, Funny)
Disgusting.
Many of us here don't take kindly to people like you who advocating violation of the Temporal Accords. As a pre-verteran of the temporal cold war I still carry the scars that conflict will inflict on me.
Re: (Score:3, Insightful)
I find many websites prohibitively slow, but it has less to do with rendering performance than bad design. Few things are more annoying than staring at a blank page saying "439 of 440 files loaded".
(Well, ok, one thing. "This site requires flash"...)
Re: (Score:2)
I find many websites prohibitively slow, but it has less to do with rendering performance than bad design. Few things are more annoying than staring at a blank page saying "439 of 440 files loaded".
I forgot which browser it was, but there's one browser that, when it encounters an empty src attribute, it tries to load something that doesn't exist, which never finishes.
Re: (Score:2)
Then you are not doing anything really complicated. Also most web sites balance their code to average browser performance. You can do a lot of stuff with the the current web browsers. They can be indistinguishable from most applications that one would say isn't Web Based. Now if developing such apps for the web platform is a good idea or not is an other debate all together. But the browser has a lot of functionality and slow JavaScript performance causes the developer to skip features or do it in a more a
Re: (Score:3, Informative)
It's pretty borderline on my eee701. I have to install noscript and adblock to keep it usable.
Re:How fast do we need? (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.
Not just Wine (Score:5, Insightful)
i usually develop on Linux, and test against Konqueror and Firefox 3, and periodically fireup a KVM virtual machine running winXP for testing against IE, Chrome, and Firefox (again).
when doing heavy JS animations, and even more when using Canvas, it's pretty obvious that FF on windows is far smoother than on Linux, even with the VM overhead.
I'd say that there are lots of optimizations that the FF/Linux dev team left out.
Re: (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, softwar
Firefox Faster In Wine (Score:5, Funny)
Firefox Faster In Wine
And here I was thinking inebriation led to slower brain functions!
about:buildconfig (Score:5, Informative)
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.
Re:Firefox is slow on Linux in general (Score:5, Interesting)
Re:Firefox is slow on Linux in general (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.
Nope, not the problem (Score:3, Insightful)
Think about it. If this WAS the problem, then running the windows version under Wine would not be faster. Wine still has to live on top of X and thus it would suffer from similar issues.
Now, it could be that the Linux port uses X BADLY and Wine uses X WELL, but that still doesn't make it an X problem.
I know that Swiftfox has not been making people (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?
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.
Recompile please (Score:3, Interesting)
Misguided effort (Score:5, Informative)
Browser response, not speed, is what annoys most people on Firefox, since version 1.
Instead, it's the lack of threading - that the notion "UI, the rending engine, and plugins should run in separate threads, with the UI thread having the highest priority".
Konqueror runs Flash player in its own process "nspluginviewer", which I can renice to 19 - just like how IE runs Flash in the lowest priority by default. Still, on Firefox 3, a few tabs running CPU-intensive Flash can still effectively freeze the browser UI.
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 ;).
Window Contents (Score:4, Informative)
Firefox appears to be using an inefficient method to render the content to the screen. If a load up a page in Firefox and drag the window around fast, the content inside the window tears and blurs and stays that way for a second after I stop whipping the window around. Konqueror and Opera don't do this.
So can you compile yourself? (Score:3, Interesting)
Can you compile Firefox & Ubuntu yourself and get better performance, then?
Has been this way for a while (Score:3, Informative)
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.
Re:Really a surprise? (Score:4, Insightful)
if you want to talk about monolithic, do-it-all library architecture... lets talk about glibc. does far far far more than any libc is needed to do.
Re:Really a surprise? (Score:5, Insightful)
Serious question: What is glibc doing that you don't think it should be doing?
Re: (Score:3, Insightful)
Re:Really a surprise? (Score:5, Funny)
I guess it's all a matter of preference. Right now my glibc is washing the dishes, which is great since my wife won't. However, in some other house they might want glibc to stay the hell out of the kitchen.
Re:Really a surprise? (Score:4, Informative)
Serious question: What is glibc doing that you don't think it should be doing?
This isn't so much a complaint about glibc-as-implementation, but I do think the standard C library design has a lot of crap in it that it just doesn't do well.
In my mind, the main offender is internationalization and localization support. It's a non-trivial problem that the standard library just isn't very well-suited to--I usually end up using a library like ICU for this.
The C people should have stuck to byte string manipulation, math, and basic I/O, but there's no putting the horse back in the barn after that.
Re:Really a surprise? (Score:4, Insightful)
Re:Really a surprise? (Score:5, Insightful)
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.
Re: (Score:2)
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.
Ah, but with FOSS, #1 is assumed (for the end users, not the developers) because FOSS can be seen as charity after a sort, it's quite possible for it to be #2, #3 for for devs, and all three for end users.
Re: (Score:3, Insightful)
No it's not. Due to developers having to foot the bill themselves, you don't get to choose one of your options. Open source software HAS to be cheap. Value is not measured in money you know. Money's just the in-between "equalizer". Value is measured in computers, development time, eyeballs, testers, people, management, internet servers, ... Just because you don't have to pay for something doesn't mean that the value you received wasn't created using resources.
Your argument would include stuff like "pirated
Re:Really a surprise? (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".
Re: (Score:3, Funny)
Actually, I think it's "Good, Fast, Cheap. Pick 2". And for online dating, it seems to be "Attractive, Intelligent, Sane. Pick 2".
More often "Pick 1"
Re:Really a surprise? (Score:4, Insightful)
Pick any two
Re:Really a surprise? (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.
Re:Really a surprise? (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.
Re:Really a surprise? (Score:5, Informative)
Actually he's right but in the wrong direction. On Wine many things that would be pure syscalls on Windows do force a context switch into the wineserver, because the emulated "kernel" is actuall a separate process. For instance opening a file involves an RPC to the wineserver on Wine, whereas it simply switches into kernel mode on Windows and there's no TLB flush overhead. The fact that Firefox is still faster under Wine than native suggests a serious bottleneck somewhere rather than a general problem - if I had to choose, I'd pick text rendering as my first guess.
Re:Really a surprise? (Score:5, Informative)
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.
Re:Really a surprise? (Score:4, Funny)
Well he said the Unix way so I'm assuming he's thinking of some sort of demented scheme involving fork() and a filter-style JS interpreter which spits out a shell script which is then piped to bash with the DOM as an HTML file and the output redirected back to Firefox. Or the official Windows binary was compiled with Intel's monolithic compiler rather than gcc.
Re:Really a surprise? (Score:4, Informative)
Context Switch also refers to switching between user and kernel modes via system calls or interrupts. OP is still a raving lunatic though.
Re:Really a surprise? (Score:4, Insightful)
You fail to realize that ultimately both versions of Firefox must eventually go through the same layers of Linux in order to do pretty much the same thing. The story is that the Windows version is still faster even though it has a whole extra layer to go through.
It is not even a comparison of Linux/Windows but of Linux and Linux+Wine.
The Linux build of Firefox is the problem here and has nothing to do with the trade-offs between how Windows does things and how Linux does things.
Besides, how can you say that everybody should fall on one side of the Performance/Reliability trade-off? Such things are case-by-case by definition.
Re:Really a surprise? (Score:4, Insightful)
Re:Really a surprise? (Score:4, Informative)
It's basically a compiler benchmark. What this proves is that the microsoft C++ compiler produces better code than gcc. This isn't suprising. Re-run the benchmark with the Linux code compiled with the intel compiler. gcc is a good compiler, but it doesn't produce code as tight as some commercial offerings.
To be honest, the quality of generated code between MSVC and gcc is not that different. MSVC tends to do inlining somewhat better (I've personally witnessed it unroll a ~60000-deep call chain - produced by template metaprogramming - into a single statement). On the other hand, gcc is sometimes more tricky with rearranging the code smartly to produce the same effect for less effort, on the level of individual instructions. I do not think that it's what makes a difference here.
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:Really a surprise? (Score:5, Informative)
Regarding your point about how the app was built: How do you draw a distinction between the Windows, Linux, and UNIX builds of Firefox? I'll help you - each version is a port using libraries on the system that it is ported to. Those dependencies do in fact have an impact on compilation, how the memory map is built, and how well the application performs.
Also - the optimization process differences are significantly more complicated than you implied. I strongly suspect, although am not positive because I have never built it from source or examined how an RPM was built, that the Linux Firefox build was done with at least -O2 or -O3 flags. The difference that FP was talking about was PGO (Profile Guided Optimization), which is more involved (and thus better performance gains) than just turning on the default compiler optimizations.
Re:Noticed this for a while now (Score:4, Informative)
the qt rewrite is dead jim.
Its a shame i was really looking forward to the qt port, but just like the old port, it got done then dropped AFAICanTell there wasn't enough developer interest and no users were using it as it wasn't quite usable :(.
Re: (Score:2)
As others have pointed out, the windows build is substantially different from the linux build. reread the thread to see how. GTK is NOT damned slow. Nautilus is.
Re: (Score:3, Informative)
... RTFA
Re: (Score:2, Informative)
Re: (Score:2)
But those benchmarks are done by a f'n noob! How can you possibly trust them?
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
http://tech.slashdot.org/comments.pl?sid=1126249&threshold=2&commentsort=0&mode=thread&cid=26836579 [slashdot.org]
We get it you don't like linux. Just go away.
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 n