Mozilla renders tables slower than IE or Opera




18 years ago
18 years ago


(Reporter: simon.britnell, Assigned: troy)



Firefox Tracking Flags

(Not tracked)





18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; N; Linux 2.2.12-20 i686; en-US; m14)
BuildID:    2000032711

Opera & IE both take <1sec to render this page.  Mozilla & Netscape both take in
the 4-5sec range.

Reproducible: Always
Steps to Reproduce:
1.Type the URL into the location bar
2.Start stopwatch while pressing enter
3.Stop stopwatch when page has rendered
(nb:images are all missing, but result is the same when images are present)

I've logged this as normal although technically its minor as it will stop us
recommending mozilla/netscape as a browser to our clients (who are picky about
response times).  The closest other bug I could find to this one comments that
rendering 9MB of text is slow (29614).  This is a bit more of a common case than
that :)

Comment 1

18 years ago
The page doesn't load in <1sec for me using IE. At least not the first time. It 
takes many seconds. A reload of the page is very fast, yes, but that's because 
IE has the document cached.

Gecko doesn't yet have a disk cache and the memory cache is currently disabled 
because it's flakey

Reassigning to Necko because we need working disk and memory caches
Assignee: troy → gordon
Component: Layout → Networking: Cache
QA Contact: petersen → tever

Comment 2

18 years ago
Be aware that is served from NZ, so bandwidth and latency may mask the
slow layout.  It may pay to download the file onto local disk and then make the
comparison.  I tried this page loading from local disk again today with the
following results:
IE <2sec
Linux Opera 0125 technology preview <1sec
Opera 4.0 beta 1 on windows <1sec
Mozilla 2000032808 (and earlier) <4sec
Netscape 4.7 <5sec

Opera and IE still seem substantially faster.

Comment 3

18 years ago
One thing of interest is that all the images that don't load will fairly 
substantially slow things down, because unlike IE and Nav when an image can't be 
rendered we use its alternate content instead.

That means we have to do an incremental reflow of those parts of the document 
that have images that don't load

If you are going to do comparisons it would be better to have no images or 
images that load

Comment 4

18 years ago
Simon confirmed that the performance when loading the page from a local file is 
okay on NT, roughy 1.5 seconds to load the page, and that the problem is Linus 

Reassigning to Kevin to understand what the Linux specific problems are
Assignee: gordon → kmcclusk
Component: Networking: Cache → Layout

Comment 5

18 years ago
confirming bug as new, to get of the unconfirmed list. sorry for the spamm
Ever confirmed: true
Waqar, another linux bug to look at.
Assignee: kmcclusk → waqar

Comment 7

18 years ago
Here is my test. From the net the time is 3.721 sec, and local webserver 1.889
sec and local file 1.349 sec. This is on a 400Mhz PII, running RedHat Linux 6.2.

This is not a Linux specific, tried this test on Windows machine IE5 loads it
very fast, almost instant, and gecko same as linux.
Assignee: waqar → troy
Severity: normal → major
OS: Linux → All
Target Milestone: --- → M16

Comment 8

18 years ago
waqar:  is your test with the images on the net, local, or the images removed?
I would test the page with images removed entirely.   Trying to optimize the
case where images can't be loaded is not a good use of time now.

Comment 9

18 years ago
I'm marking this WORKSFORME, because I determined and Simon (the bug reporter) 
agreed that performance was okay on Windows when loaded from a local file.

Waqar reported Unix performance was the same as Windows, and at this point I 
think the issue is all of the images that fail to load. That is what is slowing 
down the load of the page. That's an exceptional condition and there's not much 
we can do if that's the issue
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 10

18 years ago
marking verified per previous comments
You need to log in before you can comment on or make changes to this bug.