39133 - Performance: Loading of the above URL takes 10x more time tan IE

Status: RESOLVED INVALID

(Core :: Layout: Tables, defect, P3)

Description

[Neelakanth Nadgir]

The above table takes *much* longer to load with mozilla m15 than with IE 4.
The machine configurations were as follows.
mozilla -->Ultra10, Elite3D, 360MHz, 1GB RAM, Solaris 7.
IE -->Dell Precision410 with Windows NT 4.00.1381.
Results without decimal points were wall-clock benchmarks, and may
be off by a second.                                              
Results with a decimal point were reported in the web browser GUI;
I rounded these to the nearest tenth of a second.

Comment 1

[Neelakanth Nadgir]

The test case is available at ftp://ftp.sunmde.com/pub/i2source.html

Comment 2

[Neelakanth Nadgir]

ooops!. forgot to enter the timings.
Mozilla m15 -- 53 secs
IE -- 5 secs.

Comment 3

[Blake Ross]

Reassigning to HTMLTables (or networking, perhaps?)

reporter: please try with a later nightly build to verify this problem still 
exists.

Comment 4

[Neelakanth Nadgir]

I tried it with today nightly build (5/12/00) 
mozilla on Ultra10, Elite3D, 360MHz,512Mb RAM, Solaris 8 --> 43 seconds!

Comment 5

[Jerry Baker]

Windows 2000, 2000051620:

Mozilla: 18 seconds
IE5: 4 seconds

PS - I am marking this as confirmed since it is an issue.

Comment 6

[karnaze (gone)]

ChrisW, here is a performance bug.

Comment 7

[Neelakanth Nadgir]

Ok, Something has changed since last week(5/12/00). The times for the above url
have increased by 2x.
now, on my ultra 10
with the 05/18 nightly binary

First Load: 99.17 secs
Reload :95.469 secs

Comment 8

[Chris Waterson]

Posted raw Quantify 6.0 data at

  ftp://ftp.mozilla.org/pub/quantify/2000-06-20-39133.qfy.gz

Here are some first-order observations.

- 3% of the time spent in nsHTMLTags::LookupTag(). It's all spent
  grovelling through the AVL tree. This should probably be a
  hashtable. I guess 4.x computed a perfect hash?

- CNavDTD::WillHandleStartTag() is using NS_ConvertToString() where it
  should be using NS_LITERAL_STRING() while notifying the observer
  service. Altogether, inflating the string and notifying the observer
  is accounting for 1.77% of the time. Went ahead and changed this:
  although we'll still have to pay for the observer service, we won't
  need to inflate.

- nsBlockFrame::Reflow() accounts for 30% of the time. Of that:

  - 5% is spent in nsLineLayout::AddText(). 70% of that time is spent
    in ::operator new() creating nsTextRun objects. We're down in the
    noise, but it may make sense to recycle these or something.

  - 9% is spent nsBlockFrame::SlideLine() placing frame views. This is
    dominated by nsContainerFrame::PositionChildViews(). It's a recursive
    function, dominated by the cost of the recursion itself and
    the cost of addref-ing and release-ing atoms. Atoms are expensive
    to addref and release because it appears that they're assumed to
    be threadsafe. Argh! Sheesh, why even use atoms for this? They're
    tokens! Use enums!

Continuing to dig, but wanted to post notes somewheres.

Comment 9

[Raghu Sakleshpur]

I'm changing the OS to Linux as this bug was tested to occur on Linux platform
with M16 distribution. The additional comment here is nothing happens when
the URL is typed in.

[e-mail]

Comment 10

[Amarendra Hanumanula]

QA contact update

Comment 11

[Tom Mraz]

The testcase is no longer there.

Comment 12

[Tom Mraz]

Marking invalid because of missing testcase.

Comment 13

[Neelakanth Nadgir]

Attachment: the test case that went missing

Comment 14

[Jerry Baker]

Mass removing self from CC list.

Comment 15

[Jerry Baker]

Now I feel sumb because I have to add back. Sorry for the spam.