Closed
Bug 69020
Opened 23 years ago
Closed 17 years ago
Linux version is much slower than w32 version
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: bart, Assigned: chofmann)
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i586; en-US; 0.8) Gecko/20010215 BuildID: 0.8 I'm testing mozilla for some time, and one time that bothers me is the fact that on linux mozilla is much slower and gets more cpu/memory than win32 version (don't know about beos/mac, versions). I discuss this on a list and everbody agreed with me on this, so I'm bugzilling this. Reproducible: Always Steps to Reproduce: Have a dual boot linux/win32 system, install mozilla on both systems, run it and see the diference. Actual Results: Mozilla is muach faster, less cpu/mem consume on windows Expected Results: My hope was linux should be much faster, but if it just got the same speed than on win32 build I'll already be happy. Could this be because of gtk? I'm not a really fan of GTK, I think QT is better, and once mozilla really masks gtk under xul, you should think using the better and less cpu hunger graphic tool, even the motiff was better than gtk in this case.
Comment 1•23 years ago
|
||
Actually, the main culprit is probably g++ (which is just not a very good C++ compiler compared to VC++). This bug is not very useful. It's fairly well-known that the Linux version is slower than the Windows version. If you can point to a _particular_ case in which it is slower, then that code can be optimized more on Linux. But saying that it's just "slow" really doesn't give enough useful information.... So, anything seem particularly slow on Linux? (you may want to search for bugs that are filed on Linux and have "perf" in the keyword field to see if the things you find are known issues).
Yes, I can do it. Rendering and XUL! Mozilla takes MUCH time and memory to render it's XUL interface and the html. Just change to another window/apps and return to mozilla. It will take some page to re-render a page already loaded (!). It's easy to see the difference using galeon, maybe XUL dosen't work on linux at all? Maybe a good old way interface is better? I don't know, but can say: XUL weights a lot, and makes rendering sloooooower on linux.
There was a general rendering-bug comparing Linux/Windows, but it's marked fixed now, even if some accknowledge that various problems remain. Related open bug: 49141 "New window performance" (OS: All)
Comment 4•23 years ago
|
||
No XUL is not the problem. XUL is cross-platform, it doesn't depend on anything particular. Like Boris Zbarsky said, the real problem is probably the gcc compiler, which (I have read this in the performance newsgroups) adds 20% more bloat than egcs and VC++. In any case, we know very well that the Linux version is slower, but it is not because of XUL. I think this should be marked invalid, unless we can find something precise to work on.
What's really sad is that a win32 mozilla running under wine on Linux is faster than the native Linux version. This has been true for quite a while. I fail to see why gcc is the culprit because gcc compiles both Linux mozilla and wine. If you don't believe me,try it yourself.
Comment 6•23 years ago
|
||
Right tenthumbs, but gcc isn't user to build the Windows Mozilla, and that's where the problem is.
Well, wine *is* built with gcc so gcc itself is not the issue. It might be g++ but I'm not convinced. One would have to prove that the code has not been implicitly or explicitly written for MSVC. Actually, I think the choice of C++ is, in fact, a choice for MSVC; but I'm often wrong. In any event, no end user cares which compiler was used. If mozilla is slow, it's slow.
Comment 8•23 years ago
|
||
Gcc does indeed compile Wine. But Wine is written in straight C. gcc is a decent C compiler. It is _not_ (yet) a decent C++ compiler. Ver 3.0 will change this, is the hope. A few notes: 1) a lot of gcc optimizations are not being done yet on Mozilla because gcc 3.0 would completely fail to build files with those optimizations. So mozilla should get faster once the gcc people stabilize their C++ ABI and mozilla is optimized for it. Or so I have heard; I may be mistaken. 2) You say that users don't care. That's all good, but can you point us to a different compiler to use on Linux? What language do you suggest Mozilla be implemented in? Anyway, this discussion should probably move to the newsgroups...
Comment 9•23 years ago
|
||
i suggest a wontfix, as this bug has no concrete information about what is slowing us down that could warrant a developer taking a look at this...
Comment 10•23 years ago
|
||
yesterday I also saw the huge speed difference between Linux and Windows. Has someone tried to compile Mozilla with gcc 3.0 and can say if Mozilla got faster? Is there still a performance difference to the windows version?
Reporter | ||
Comment 11•23 years ago
|
||
I don't think it's a good idea close this bug, this could let mozilla 1.0 goes out rwally with problems on the linux plataform. You can say it's not a bug, but I think is a program major program, call it as you want, to me is a bug, and the place of bugs is bugzilla, so developers don't forget about it :)
Comment 12•23 years ago
|
||
removing myself from CC.. don't want to be spammed by such a bug i'm sending this to chofmann so he can decide
Assignee: asa → chofmann
Comment 13•23 years ago
|
||
this bug is too general, there is no information as to what code is the culprit (blaming XUL in general). If you want embedded moz on linux, take a look at kmeleon...
Assignee | ||
Comment 14•23 years ago
|
||
is this a page loading diff, UI manipulation... lets get a list of the tasks you have timed and found slower, then lets start rolling through the list doing profiling work to see which operations show the greatest speed diffs, then lets see if the compiler, os, arch, or what factors are coming into play. this could be a tracking bug for a whole list of problems that might need to be fixed. I'll leave it open a bit to see if we can get some folks pitching in on the work to make this a useful bug.
Reporter | ||
Comment 15•23 years ago
|
||
Ok, I'll try bo be the more specific I can.... Linux version seems to need more cpu/memory to render html Rendering html on windows seems to be faster - specificaly on drawing, forms, etc seems to drawn faster on windows Sometimes (a lot of times I should say) when you let mozilla on background, after a while when you return to it, it simply don't draw nothing for a good while (sometimes 1 minute or more), even XUL interface isn't draw on screen, you seel only a gray screen on whe window - I think this is the bigger representation of linux version problems, on win32 I didn't saw that. If you need more info, and teach me how I can try doing some tests, debugging, etc, compare windows and linux rendering speed, etc. I want to help solve this, because if mozilla don't gets faster and consume less memory I will not be able to use it as main browser.
Comment 16•23 years ago
|
||
cc: asa in case he has any interests
Reporter | ||
Comment 17•23 years ago
|
||
Open new window - win98SE - RedHat 6.2 ~2 sec ~5sec Load blizzard.com ~12 sec ~16sec On windows, opening 3 windows cause no performace degree on the computer, on Linux 3 windows open almost stops everthing. I think most than speed, there are memory problem, this really seems compiler problem plus code optimization (I was wrong, ok, sorry, it's not 100% XUL guilt, just a part). What are the solutions? Use another compiler? (think borland have one C compiler for linux). Still for a browser than is supposed to be embeded, mozilla (even on windows) is too slow, too fat. Being (we are already at 0.8, don't tell me this will be made later) slower than netscape 4 isn't a good thing :) What can I say? Maybe mozilla needs a speedzilla day as the bugzilla day?
Reporter | ||
Comment 18•23 years ago
|
||
More about this: I just installed the thinice skin and the speed improvement I got is really great, mozilla is running well with this skin. So, maybe xul have still some part on the guilt for slowdown?
Comment 19•23 years ago
|
||
hewitt checked in some modern stuff that sped it up for me on linux (new window in 2 seconds LM 7.1 PII 400 256 MB ram).
Comment 20•23 years ago
|
||
While reading the status report of this week I found the following URL. It shows the performance of some tasks under Linux, Windows and MacOS. It clearly shows in hard numbers, that the Linux version quite abit slower than the windows version (usually by 10-30%). On the other hand, MacOS is even slower in most cases... Anyway, I think we can remove this ugly "unconfirmed" and set this bug to "new" :-) http://www.mozilla.org/quality/perf/browser-archive/preferences.html Interesting is, that "Open Preferences dialog" got slower since 6.01 on linux, while it got faster on windows. Sadly for 6.01 only few numbers are given...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 21•23 years ago
|
||
could please someone look under the following URL under the subject "Buried in VMAs" http://lwn.net/2001/0809/kernel.php3 more details / analizing can be found under: http://lwn.net/2001/0809/a/vma-analysis.php3 Some optimizations in the kernel (VMA, virtual memory areas) conflict with the way, the glibc handles memory. Mozilla runs slow under 2.4 kernel, because it has 5000 VMA's, while NS4 only had 54 of them. One would have to change the way, glibc handles memory to get a speed up.
Comment 22•23 years ago
|
||
I have an idea: How about a time tracker build in Mozilla? In the QA menu there could be an entry "speed test". With this Mozilla could get some of the test pages and produce a statistic that then could be send to Bugzilla. With this many user could send statistical data. If the test pages test different parts of the engine, than it should be possible to get vers good answers what page features slow down the Mozilla Linux version.
Comment 23•22 years ago
|
||
Adding myself to CC list
Comment 24•22 years ago
|
||
Compiled Mozilla 1.1 CVS branch with GCC 3.2... speed is still a snail... If I just type a URI in the Address bar I need to wait nearly 7 seconds to see it. Back when I used Windoze, Mozilla was just as fast (if not faster) than MSIE. Also, I suggest the Severity of the bug be changed to major... this speed is nearly unusable >_<
Comment 25•22 years ago
|
||
Luke-Jr -- you built non-debug and optimized, right?
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 26•17 years ago
|
||
(In reply to comment #1) > This bug is not very useful. It's fairly well-known that the Linux version is > slower than the Windows version. If you can point to a _particular_ case in > which it is slower, then that code can be optimized more on Linux. But saying > that it's just "slow" really doesn't give enough useful information.... I thing all disscution in https://bugzilla.mozilla.org/show_bug.cgi?id=90198 can provide a lot of samples on how it is. I don't believe that the problem is in compilation things...
Comment 27•17 years ago
|
||
resolving INVALID -- this bug is not useful. specific problems should live in separate bugs.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
Comment 28•17 years ago
|
||
(In reply to comment #27) > resolving INVALID -- this bug is not useful. specific problems should live in > separate bugs. > It's all about the same thing: in Linux, Firefox is far much slower than in Windows. We just don't know why, yet. This place is for discussing the problem, isn't it? So we have to try the possibilities.
Comment 29•17 years ago
|
||
Actually, we do have a good idea for some reasons why. See comment 1. MSVC consistently produces smaller and faster code than GCC does from the Mozilla source (faster even in simple terms like "look at the assembly -- there are fewer instructions). Smaller code is key for an app like Mozilla if we're to stay anywhere near inside the instruction (or even the shared L2 on x86) cache. But then again, people didn't believe me 6 years ago; why believe me now?
You need to log in
before you can comment on or make changes to this bug.
Description
•