Firefox Javascript na Linuxe a Windowse
Nelichotivé výsledky pre Firefox Javascript na Linuxe voči Javascript-u na Windows, ukázali viaceré benchmarks. Windowsácky Firefox bol absolútne najrýchlejší zo všetkých a dokonca aj Firefox spúštaný vo Wine (Fedora 10) bol rýchlejší ako natívny linuxový Firefox! Zdroj správy a ďalšie info na tuxradar.com.
Pre pridávanie komentárov sa musíte prihlásiť.
Where does this difference come from?
I think it makes sense to think about where this difference comes from. Some thoughts about possible and impossible reasons:
* Anything used both by native Firefor and Firefox on Wine can't be responsible (e.g. the slowness clearly isn't due to X, because X is used by Wine as well).
* If the slowdown is graphics related, maybe the used toolkit (GTK I think) is responsible for the slowdown. If this is the case, every app using gtk on Linux and native GUI on Windows should be slower on Linux than its Windows equivalent. If that is the case, optimizing GTK (or switching to another, faster toolkit) would be the solution.
* If the slowdown is compiler related, the solution is to get better compiled executables. Maybe the solution would be as simple as getting the vendors to use the appropriate options; I thing many GCC users don't know that if they don't give appropriate options, GCC still creates 80386 compatible code, and therefore won't take advantage of any of the great features newer processors offer. I don't think there are many Firefox users who still use an 80386. But maybe GCC just doesn't produce as fast code even with the right options. In that case, one solution would be to compile with another compiler (ICC, LLVM). Another solution would be to make GCC optimize better.
* Another possibility is that the standard library supplied with GCC/Linux is slower than the standard library supplied with MSVC/Windows (this of course only applies if Firefox makes noticeable use of the standard library). In that case, the solution of course would be to improve the standard library.
* Yet another possibility would be that the Linux calling conventions are inherently slower than the Windows calling conventions. If that is the case, the only solution would be to get better calling conventions for Linux. Probably those different calling conventions would be enabled only through options, or by function attributes, in order to not break backwards compatibility.
* There's also the possibility that the Linux related Firefox code is just not as well hand-optimized as the Windows related one. The correct solution to this is obvious.
* Related, but different is the possibility that the general code is better tuned for Windows. This need not be deliberate; it may just be that most profiling is done on Windows, and changes which improve the speed on Windows actually degrade Linux performance. The solution to that would, of course, be to have more Mozilla profiling done on Linux.