33505 - Mozilla renders tables slower than IE or Opera

Status: VERIFIED WORKSFORME

(Core :: Layout, defect, P3)

Description

[simon.britnell]

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

[troy]

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

Comment 2

[simon.britnell]

Be aware that peace.com 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

[troy]

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

[troy]

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 
specific.

Reassigning to Kevin to understand what the Linux specific problems are

Comment 5

[Doron Rosenberg (IBM)]

confirming bug as new, to get of the unconfirmed list. sorry for the spamm

Comment 6

[Kevin McCluskey (gone)]

Waqar, another linux bug to look at.

Comment 7

[waqar]

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.

Comment 8

[buster]

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

[troy]

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

Comment 10

[Tom Everingham]

marking verified per previous comments