Closed Bug 69020 Opened 23 years ago Closed 17 years ago

Linux version is much slower than w32 version

Categories

(SeaMonkey :: General, defect)

x86
Linux
defect
Not set
normal

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.
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)
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.
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.
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...
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...
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?
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 :)
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
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...
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.  
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.
cc: asa in case he has any interests
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?
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?
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).
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
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.
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.
Adding myself to CC list
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 >_<
Luke-Jr -- you built non-debug and optimized, right?
Product: Browser → Seamonkey
(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...
resolving INVALID -- this bug is not useful.  specific problems should live in separate bugs.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
(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.
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.