40988 - incredibly slow Javascript/DOM performance

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Joe Hewitt]

I've been comparing the speed of Javascript DOM element creation in Mozilla and 
IE5, and the results are very sad in Mozilla (using build 2000052508).

The focus of the test is how fast can each browser create, append, and position 
a large number of HTML elements, specifically 1000 of them.  Under IE, it took 
500ms to create the elements, and under Mozilla it took 3 times as long, at 
around 1700ms.  The worst part is, however, that when you continually add 
another round of 1000 elements, IE continues to take 500ms per 1000, but 
Mozilla gets twice as slow each round, so elements 0-1000 take 1700ms, 1000-
2000 take 3700ms, and then 4400ms, 5657ms, etc.. By the time you've got 3000 
elements on the page, the browser is pretty much unusably slow and frozen.

The bottom line is that as of this build, Mozilla can't handle large amounts of 
elements in the document, and IE5 has no problem with them.  This is going to 
negatively impact anyone building a complex UI with Javascript.  I'm hoping the 
next few months of optimization have an impact on this slowness.

By the way, I ran the tests on a Dual PIII 450mhz machine w/ 256MB RAM running 
Win2K.  If it's this slow on this box, you can imagine how slow it is on the 
average users's machine.

Comment 1

[Joe Hewitt]

Attachment: test case I used

Comment 2

[Chris Waterson]

-> DOM Level 1

Comment 3

[Tim Hill]

I'm having a similar problem.  I'm creating an XUL UI that requires that button 
and menu elements be dynamically added and deleted.  I wanted to time how fast 
this was happening.  I looped the procedure that allocated/appended/deleted 
about 50 buttons, for 100 iterations.  Each time, it just got slower and slower 
by increments of about 100ms.  It started out at about 500ms, and sometimes by 
the end it went up all the way up to 3+ seconds.  When I timed the allocation 
and insertion separately, it appeared that the insertion (using node.appendChild
(newchild) ) was the primary source of the slowness.  Allocation was fairly 
consistent.
  
I reset my computer, seeing if a fresh boot would affect the problem.  It 
seemed to be less severe, but it still took longer each time through the loop.  
Oddly, sometimes it resets so it takes the minimum amount of time (500ms), but 
I haven't been able to determine when exactly this happens.  Note that I 
deleted the items each time through the loop rather than continually adding 
them. 

I ran this on a Pentium Pro 200, Windows NT 4.0.

Comment 4

[Chris Waterson]

stealing

Comment 5

[Jan Carpenter]

Mass update of qa contact

Comment 6

[chris hofmann]

sounds like a topperf???

where should the investigation on this go next?

maybe mcafee could profile the test case?

Comment 7

[Chris Waterson]

I think we should look at it, but this is sort of an edge case: I doubt many web
pages are going to be using W3C L1 DOM APIs to create 1,000's of elements...

Comment 8

[Johnny Stenback (:jst)]

Edward, didn't you see this as well a while ago? Didn't you track this down to a
method in the view-manager that had some really badly performing algorithms in
it when dealing with thousands of absolutely positioned elements, do you
remember where that was?

Comment 9

[Edward Kandrot]

The problem I had found a bit ago was an n^2 code problem in
nsViewManager2::OptimizeDisplayList.  It walks the list of squares to see if any
are total obsucred by other rects, and if so, removes them from the list.  With
a lot of objects, mozilla became unusable quickly, commenting out this method
made us match IE's speed (pretty much).  10 calls to this method invoked
50,000,000 calls to nsRect::InerestRect and 50,000,000 calls to
nsVoidArray::ElementAt in the test case I used.

Comment 10

[Brendan Eich [:brendan]]

Someone mentioned view manager, so my cc-bot is cc'ing [e-mail].

/be

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The new view manager does OptimizeDisplayList differently. It avoids the O(n^2) 
loop but maybe still has problems because we do O(n) region operations where the 
regions could end up containing O(n) rectangles each. We will need to revisit 
Edward's test case with the new view manager.

However, since OptimizeDisplayList only happens when we paint, it shouldn't be 
involved in the problems originally reported in this bug (assuming Joe wasn't 
trying to paint every time he added an element).

Comment 12

[Prashant Desale]

QA contact Update

Comment 13

[Joe Hewitt (gone)]

Just when I thought we were catching up to IE in terms of DHTML speed, I found
this page:

http://undefined.org/play/5K3D.html

This is unbearingly slow in Mozilla, but blazing in IE.

Comment 14

[jsulem]

Selecting mail in Hotmail is very slow when viewing mail folders with many items
(and noticeably slow for only a few).  Javascript is run every time an item is
checked/unchecked that enumerates every object on the page, and checks if it is
a checked checkbox (the purpose being to automatically check/uncheck a 'select
all items' checkbox when the user manually does this).

This is on a PIII 500 with 196MB RAM running Windows 2000.

Comment 15

[Johnny Stenback (:jst)]

jsulem, what mozilla build are you running?

Comment 16

[Fabian Guisset]

[e-mail], the bug you are reporting has been fixed for about
a month, please use a newer nightly or 0.9, thanks. (and yourself to the CC list
when you comment in a bug ;)

Comment 17

[Oliver Klee]

*** Bug 82706 has been marked as a duplicate of this bug. ***

Comment 18

[Oliver Klee]

Copied from bug 82706:

I ran a few tests:
1) increment a variable 1 million times
2) createElement 10,000 times
3) appendChild 10,000 times

Based on these, I was surprized to see that already in test 1, Mozilla is 3.5 
times slower than IE. In Test 2, this number increased to 5.5 times slower. But 
when I performed test 3, I just couldn't believe it: I first thought the 
browser was frozed when after 28 seconds, the browser responded again... IE 
does the same task in 1 second. So here (very complicated math...) we are 28 
times slower than IE.

Of course I know you never really do such things, you create 10, 20 elements, 
and then everything happens quite fast. But the fact is, Mozilla is slower.

This is not a rant, so please don't flame me. I didn't find another similar bug 
report, but I don't exclude the possibility this one is a dupe.

------- Additional Comments From Erich 'Ricky' Iseli 2001-05-25 06:53 -------

I wanted to post the script as Attachment, but due to some firewall 
restrictions in my company, it didn't get through, so here it is:

<html>
<head>
<title>Test</title>
<script type="text/javascript">
function init() {
myHome = document.getElementById("home");
var first = new Date();
var start = first.getMilliseconds()+(first.getSeconds()*1000)+(first.getMinutes
()*60000);
for (i=0;i<10000;i++) {
  newDiv = document.createElement("div");
  myHome.appendChild(newDiv);
}
var last = new Date();
var end = last.getMilliseconds()+(last.getSeconds()*1000)+(last.getMinutes()
*60000);
alert("It took "+(end-start)/1000+" seconds to create 10,000 divs.");
}
</script>
</head>
<body id="home" onload="init()">
</body>
</html>

------- Additional Comments From Stephan Jaensch 2001-05-25 09:05 -------

To show you that this is not only a benchmark thing, but can also be noticed on
some web sites: try the JavaScript menu on http://www.arcor.net with IE and
Mozilla. Notice how slow it is with Moz compared to IE.

Comment 19

[James Green]

CVS Tip build from yesterday on Linux with --disable-debug --enable-optimize=-O2
on the testcase:

17 secs for one run of the DHTML. End dialog gave 11424 as the number.

This on a K6-2 300 w/ 256Mb RAM. All/All.

Comment 20

[James Green]

Try this for a laugh. Using Linux, install VMWare, then install Win2K Pro into
it and update to SP2. Now install last night's nightly build.

Bear in mind here that vmware is slower in windowed mode than in fullscreen. I
tested in windowed mode.

The attached testcase, run once, completes in 12 seconds, giving a number in the
dialog of 9824.

We are _far_ faster at doing things in Windows than Linux, even when running
through vmware!

Comment 21

[Prashant Desale]

Updating QA contact to Shivakiran Tummala.

Comment 22

[Taras Tielkes]

This performance issue is very visible for me.

Some webapps I built use a DHTML interface, and load XML data for the server
"out of band". This data is inserted into the view using the DOM1 methods.
Mapping 10*100 matrices (schedule tables, reports etc) shows a distinct speed
difference between IE5+ and Mozilla.

I can also confirm that the delay gets worse when the targer document is larger.

Although it is not the cause of this, I rememeber from news group discussions
with Vidur a year and a half ago that the implementation of getElementById() was
                 pretty inefficient. I don't know if this is still the case, but
it might be worth checking. Not that it will help any in most scenarios...    

Comment 23

[Dimitrios]

I am attaching the following test case to show the slugishness of a javascript
menu. Unzip the file in a folder, open index.html and click on some submenus. On
Mozilla, it takes about 4 sec to refresh everything after a click (html content
is minimal, so it doesn't affect). Delay is increased with the number of
horizontal menu items. IE needs less than 0.5 sec and it doesn't seem to be
affected by the number of menu items.
Tested with build 2001071004, Win98, K6-3/400 (256kb L2 cache), 192 MB ram,
Voodoo 2000 graphics card.

Comment 24

[Dimitrios]

Attachment: Test page with javascript menu

Comment 25

[Dimitrios]

Attachment: Another try (wrong type declared)

Comment 26

[Brent Gustafson]

This has been my biggest complaint w/ Mozilla thus far.  I do a lot of 
animation w/ DHTML, and animating more than 2 things on the screen at once w/ 
Mozilla slows the animation down considerably from what would be full speed 
(and this is on a PIII 750).  I've seen IE animate well over 10 objects at once 
at full speeed.  For an example of slowdown, check out this page:

http://assembler.org/XLAT/0E/index.html

When I can get this page to perform to the same level as IE, I'll be happy.  So 
far however, I haven't seen many performance gains on the Mozilla side.  And 
don't even get me started on the performance on a Mac.  Is this even being 
worked on or looked into?  Will 1.0 have acceptable JS/DOM/DHTML performance on 
par w/ IE?  I sure hope so, or the web is going to continue to use IE only for 
all it's neat little JS tricks.

Added myself to CC:

Comment 27

[Benjamin Mucci]

http://www.culina.qc.ca/reservation/reservation.html is a exemple of the
EXTREMELY bad performances of Moz on JS form. The other exemple is
http://www.mozilla.org/quality/help/bugzilla-helper.html when selecting the
"Product" and the "Component" menu is updated.  NS4.7 is instantaneous... Moz is
quite depressing.

Comment 28

[Simon Fraser [no longer active]]

Serious performance problems with pages that dynamically change the contents of 
form controls are known, and covered, somewhat, by bug 62568 and bug 60137.

Comment 29

[Jason Tackaberry]

I'm building an app using the DOM and Javascript, targetting Mozilla and IE5.5+.
 Populating a table of 500 rows (5 columns) takes roughly twice as long in
Mozilla compared to IE5.5 and 6.0.  Athlon 1.4Ghz, 512MB RAM, adding 500 rows
takes 10 seconds.  With IE6.0 (running through vmware) it takes 5 seconds.

From what I can see the slowness is as a result of createElement, and not
appendChild.  Storing the existing 500 rows in an array, clearing the table, and
reinserting the rows using appendChild takes roughly 4 seconds on Mozilla.  It
also takes roughly 4 seconds with IE, so it appears the real performance loss
compared to IE is in createElement.

I wish I knew some optimization tricks, but I'd especially like to see Mozilla
parellel IE in terms of performance.  Using Linux build 2001090508 for the above
numbers.

Comment 30

[Johnny Stenback (:jst)]

Jason, could you attach a testcase that shows the speed difference between IE
and mozilla when creating elements, that would greatly help in fixing this
problem, thanks!

Comment 31

[Jason Tackaberry]

Funny how things work out, isn't it?  I built a test case last night and
discovered that Mozilla completed it over 2 seconds faster than IE (4.5s vs.
6.6s).  So my createElement observation was a red herring.

The offending code in my web app clearly executes faster in IE, however, but
that section of code does a lot more than just populate a table.  (It is
essentially a listview control.)  I'll have to further profile the code to find
out where the slowness in Mozilla is, but after some preliminary testing I
suspect the problem is in assigning the object attributes (col.style.paddingLeft
= "4px" for example).  Sprinkling in some of those assignments into the testcase
loop increased both times quite a bit, but IE pulled ahead (10s vs 13s).  This
isn't significant, but since my code does quite a bit of those types of
assignments I can see a 2x difference.

I noticed I was able to optimize my listview code a bit by presetting some of
the styles in an external css and setting className, but since a lot of the
styles in the listview widget need to be calculated dynamically (i.e. font and
color based on content, background color of each row based on their position in
the list, etc.) I was only able to shave off about 10% of the difference
(Mozilla 7.7s vs. IE6 12.4s in one test). 

Anyway, I will work up a test case that manages to execute 2X faster in IE -- I
suspect that will just be a matter of adding the right number of col.style.*
assignments. :)

Comment 32

[Johnny Stenback (:jst)]

Jason, thanks for looking into this more, setting element.style.foo in mozilla
is known to be slow, we end up doing way too much work in layout when style
properties are modified, there's a whole forest of bugs on that already :-)

If you already have a testcase you can attach then please do so, but if you'd
haveto spend much time creating one, don't bother unless you wanto.

Comment 33

[Ari]

This page (http://www.cs.brown.edu/courses/cs051/) is another exmaple of slow
JavaScript performance on Mozilla. In this page, hovering over the 'newer' and
'older' links on  the left side causes the news pane to scroll. The news pane
scrolls much more slowly on the 8/27/01 Mac OS X trunk build than it does in
other browsers such as IE 5.1 Preview for Mac OS X.


Scrolling is implemented on this page using setTimeout(...), so i assume that
the slowness is in that function. The code for scrolling is at:
http://www.cs.brown.edu/courses/cs051/src/scrollops.js

I don't know if this problem is confined to the Mac OS X build. I also don't
know whether I should file a separate bug for this since this example is not
related to creating DOM objects.

Comment 34

[Brian Rogers]

On build 2001092803 in Win2k on a Celeron 500 with 448 megs of RAM, the speed on
that site is about the same as with IE5.  Though the CPU usage is around 50% in
Mozilla, and 5% in IE, so this site still displays a performance problem.

The issue with the scrollbars is bug 45597.

Comment 35

[ArronM (:paper)]

I created a very simple testcase for Bug 64516 which applies to this bug as well
(if not more so)
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=56446
Setting Style Properties Slow / CPU Hogging

Mozilla is notibly slower compared to IE, and uses most of the CPU (compared to
the 5% that IE gets)
Is there a specific bug for setting style properties being slow?  I've counted
about 6 bugs that all suffer from slowdowns directly related to setting styles
in DHTML.

Comment 36

[Chu Alan]

A simple test suggests that the cause may be because of massive function calling
when function calls are pretty slow in mozilla ...

Comment 37

[Brendan Eich [:brendan]]

Chu Alan: What simple test?  What kind of function calls?

/be

Comment 38

[Petr Kures]

Maybe I'am wrong, but IMHO it looks like bug 75121 (inefficient incremental
reflow targeted at absolutely positioned block frames). Does setting position on
div block cause incremental reflow (I think so)?

Comment 39

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 40

[Asa Dotzler [:asa]]

don't move bugs that are in the 1.0 dependency tree. sorry.

Comment 41

[Markus Hübner]

See Bug 117611 for JS performance issues

Comment 42

[Markus Hübner]

See bug 118933 for DOM performance issues.

Comment 43

[Tom Mraz]

Changing the dependency, because the originaly reported issue is especially DOM
issue.

Comment 44

[Markus Hübner]

nice JavaScript Performance test-suite: 
http://www.24fun.com/downloadcenter/benchjs/benchjs.html

Comment 45

[Alistair Phipps]

Came across this (I think) today with a Javascript scrolling text display.  Had
something like:

document.getElementById("divID").style.top =
(parseInt(document.getElementById("divID").style.top) - 1) + "px";

And this was *very* slow (took 100% CPU when called every 20ms on a PIII450). 
Change the "- 1" to "- 0" and it takes close to 0% CPU.  Was very fast (low CPU
usage) on IE.

Comment 46

[Markus Hübner]

@darkfox: do you have a testcase of that somewhere?

Comment 47

[Alistair Phipps]

http://www.utilitygis.com/ is the page that I was referring to, that exhibits
100% CPU usage with the Javascript scroller in Mozilla.

The scroller uses this Javascript code:
http://www.utilitygis.com/includes/mvmScroller.js

I'm afraid I don't have a simple testcase for it, but the scroller itself isn't
too hard to follow.

Comment 48

[Mike Calmus]

Attachment: JavaScript Clock follows cursor

Another test case. It's a bit hard to follow because of all the math, but
beyond that it's pretty simple.

Comment 49

[Markus Hübner]

Results from tests at
http://www.24fun.com/downloadcenter/benchjs/benchjs.html

            trunk 2002121108     msie6 sp1
-------------------------------------------
test1       34.529sec            29.622sec            
test2        5.087sec            15.963sec
test3        1.473sec             5.568sec 
test4        1.583sec             3.615sec
test5        0.761sec             4.496sec

Are we really that good?! :)

Though the testcase as mentioned in comment #1 still shows major performance 
problems.

trunk 2002121108 - 661ms
msie6 sp1        - 231ms

More of those tests where we are really bad (createElement, getAttribute, 
etc.) are mentioned in bug 118933.

Comment 50

[Erich 'Ricky' Iseli]

Since I'm on Linux, I cannot compare to IE.  But my results were quite similar
to yours. Except from the first one: I got it done in 2.133 seconds, with my
133MHz processor. I found out the cause too: I'm forbidding to change the
statusbar text. So this is slowing all the things down.

Comment 51

[Benjamin Mucci]

In reference to comment 49... If I put my cursor over a link (hand cursor) test
1 takes 14 secs. Otherwise (when the arrow cursor is displayed) it takes 48
secs. Windows 98 (PIII / 800) with Moz 1.3a release.

I don't see this behavior under MacOS 8.6 (Mozilla/5.0 (Macintosh; U; PPC;
en-US; rv:1.3a) Gecko/20021213).

Under MacOS X test 1 seems to work 50% of the time (Moz 1.2.1)... but when it
works... I can't reproduce the Windows behavior.

Comment 52

[Eric Braun]

I'm trying to get my mother to use mozilla and she pointed me to
www.bigcharts.com and its javacharts running much faster on ie than mozilla.

Comment 53

[bugzilla]

The last comment on this bug is almost a year old.
Mozilla's performance manipulating the DOM still lags very much behind IE.
It makes browsing http://www.nrc-handelsblad.nl a pain (it takes ages to build
the menu on the left side).

Comment 54

[Markus Hübner]

This bug has become quite a mess - what is more effective is a reduced 
testcase illustrating the problem. So if you could make a testcase of the 
DHTML menu used at handelsblad.nl that'll serve best for profiling and further 
investigating the problem.

Comment 55

[Boris Zbarsky [:bzbarsky]]

So I just took a look at the original testcase in this bug.  The O(N^2) growth
is caused by the fact that frames are a linked list, so adding a new frame at
the end of the list requires traversing the whole list.  The time to run that
testcase (I upped the number of iterations by a factor of 10) is dominated by
these traversals).

The one exception to this is the view list traversal in IsViewInserted.  Could
we move that over to using a bit on nsIView or something?

Comment 56

[Boris Zbarsky [:bzbarsky]]

I filed bug 233441 on IsViewInserted.

Comment 57

[Christian :Biesinger (don't email me, ping me on IRC)]

>So I just took a look at the original testcase in this bug.  The O(N^2) growth
>is caused by the fact that frames are a linked list, so adding a new frame at
>the end of the list requires traversing the whole list. 

ew, that sucks. would it be possible to keep a pointer to the last element in
the list? Or to insert at the front instead of at the back?

Comment 58

[Boris Zbarsky [:bzbarsky]]

(In reply to comment #57)
> would it be possible to keep a pointer to the last element in the list?

"maybe".  It's a bit of bloat...

> Or to insert at the front instead of at the back?

The problem is that during reflow and painting he list does need to be processed
from earlier to later frames.

Comment 59

[Nicholas Allen]

bz-

It's a bit of bloat, but one pointer per frame list seems pretty insubstantial.
 How many lists are we creating in relation to the size of the content in the
frames?

Also, I noticed that nsHTMLFramesetFrame::CanResize seems to abuse the linked
list structure pretty hard.  It does a random access lookup then lets
CanChildResize repeat the lookup.  It also uses random access lookups in a loop
for consecutive frames.  Does that impact this bug or something separate?

Comment 60

[Boris Zbarsky [:bzbarsky]]

> How many lists are we creating in relation to the size of the content in the
> frames?

The problem is that each frame would need a "end of child list" pointer.
Including each text frame, if we put it on nsFrame.

> How many lists are we creating in relation to the size of the content in the
> frames?

Good question.  In some cases (eg tables) the number of frames created for a
tiny bit of content is rather large....

> Does that impact this bug or something separate?

No relation to this bug (do you see any framesets here?).

In fact, can you think of cases where we would have a lot of children of a
frameset and wouldn't be having severe issues no matter what that frame does? 
;)  The content of a child of a frameset _is_ huge, unlike the content of a
textframe.

Comment 61

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It would be on nsContainerFrame, from which nsTextFrame doesn't inherit.  And I
think shaver had a patch for something like that way back when.

Comment 62

[Boris Zbarsky [:bzbarsky]]

Hmm.. I guess we could just add a GetLastChild() to nsIFrame (a la
GetFirstChild()) and let frames implement it as they will, huh?  In particular,
we could toss faster LastChild() methods on nsFrameList (per comment 57 and 59).

That still leaves nsLineBox::LastChild (the other major time user on that
testcase), but...

I've filed bug 233463 on the nsIFrame stuff.  Not sure what a good solution
would be for nsLineBox....

For posterity's sake, here is the top of the profile for that testcase:

Total hit count: 2238
Count %Total  Function Name
313   14.0     nsViewManager::IsViewInserted(nsView*)
291   13.0     nsLineBox::LastChild() const
275   12.3     nsLayoutUtils::GetLastSibling(nsIFrame*)
173   7.7     nsFrameList::LastChild() const
150   6.7     nsLineBox::IndexOf(nsIFrame*) const
111   5.0     nsAttrAndChildArray::IndexOfChild(nsIContent*) const

nsLineBox::IndexOf is called by sLineBox::RFindLineContaining, which is called
by nsBlockFrame::AddFrames, which is called by nsBlockFrame::AppendFrames.  Not
quite sure what can be done so speed that up...

nsAttrAndChildArray::IndexOfChild is called by
nsLayoutUtils::CompareTreePosition (via IndexOf() on nsIContent).  I almost
wonder whether it would be worth it to optimize for the case when aContent1 or
aContent2 is the last child of its parent (O(1) check, instead of the O(N)
IndexOf()).  Roc, what do you think?

Comment 63

[Boris Zbarsky [:bzbarsky]]

I tried the suggestion in comment 62 for CompareTreePosition, and it cuts the
time in nsAttrAndChildArray by a factor of 2 (about 2% of total time).  Not too
much at all, especially considering how contrived this testcase is...  Probably
not worth bothering.

Comment 64

[liam Carton]

Hi,

I have a script (real world) that does do 1,000 of W3C L1 DOM interactions.

It was originally an IE only sortable / filterable table.

But, unfortunately, I have to port it to firefox.

There are between 400 and 2,000 rows of data.

Now the sort for 1,200 rows takes around 1 second on IE, and 3 on firfox.

This basically sorts the data, then insets each row in the correct place.

(Incidentally this is optimised code, and the old IE version took about 2 sec. 
However, where I to try only for IE support I am fairly sure I could get 
another 20-40% boost).

However, when filtering the results are disastrous for FF.

To filter down from 1,200 to 100 takes IE less than 1 sec.

FF takes over 3 minutes!  That is 1,800 times as slow. At first I though the 
browser had gone castors up on me!

And the code only sets the row's style.display to 'none'.

In IE the number of rows hidden doesn't really affect the timings, but in FF 
the more that are hidden the slower it gets.

Also, as it processes each row it gets progressively slower. Rows 1-100 are 
very fast, but 100-300 begins taking noticeable time, and by row 1,000 each row 
takes about 2 seconds to process.

This doesn't seem to be a memory issue as FF uses about 20% less than IE, and 
doesn't seem to grow.  From this I think that maybe the memory is in some way 
capped, and reuse becomes more and more an issue.

Just for reference:

Test machine: P4 2.66Ghz, 512Mb RAM.

IE 6.02
FF 1.06

Ultimately it makes the FF version unusable.

Comment 65

[Robert O'Callahan (:roc) (email my personal email if necessary)]

liam: two things. First, that should be reported as a separate bug. Second, try
it on Firefox 1.5 builds (Deer Park Alpha 2) ... and only file if it's still a
problem there.

Comment 66

[Boris Zbarsky [:bzbarsky]]

liam, see comment 65.  Also, please cc me on the new bug you file and make sure
to attach an HTML page showing the problem to the bug!

Comment 67

[Chris McAfee]

liam, post the content that is causing this problem, this might be a good performance test that we could 
add to a firefox tinderbox build.

Comment 68

[liam Carton]

Robert O'Callahan suggested I try this on Deer Park and if there were still 
problems to submit as a new bug.

There were still problems, though they are different now (Filter OK, Sort V. 
slow).

Have now enter this as a new bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=305898

Source included.

Thanks for the quick response guys.

Comment 69

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

It's very impressive. I just tested this bug with the first testcase ( https://bugzilla.mozilla.org/attachment.cgi?id=9328 ), comparing Fx3 with Safari 3.1.1. The result is discouraging... even if I click 10-20 times on "Append Children", elapsed time is always ~50ms. After the first click on Fx3, elapsed time is ~230ms, and it grows after every other click! After 10 clicks, the time is ~3300.

Comment 70

[Boris Zbarsky [:bzbarsky]]

Uh... yes.  That's what you get with O(N) getting of last frames.  Not exactly a surprise.

Comment 71

[Boris Zbarsky [:bzbarsky]]

With the patches for bug 233463, bug 512336, bug 512471, bug 516742 things seem to be behaving somewhat better (though I see nothing like comment 69 even without those patches).  But then I ran into bug 516857 and bug 516864.  Need to reprofile once those are fixed.

Comment 72

[Guilherme Lima]

Testing testcase from comment #1 on Windows XP:

Latest nightly (Gecko/20110114 Firefox/4.0b10pre) I constantly get around 60.
Google Chrome 8.0.552.237 I get around 29.
And on IE8 I get 125.

So, Firefox doesn't get worse each time, but it's slower than GC. Because of https://bugzilla.mozilla.org/show_bug.cgi?id=516857?

Comment 73

[Boris Zbarsky [:bzbarsky]]

Yes.  If I comment out the three expando sets, our time drops by a factor of 2 over here; Chrome's doesn't change.  So you're seeing a combination of slower DOM access from JM (covered by various bugs) and bug 516857.

Comment 74

[Boris Zbarsky [:bzbarsky]]

The next obvious issue here is bug 712874.

Comment 75

[David Bruant]

This all look fairly quick to me on Aurora 28. RESOLVED FIXED?

Comment 76

[Guilherme Lima]

I get 30~50 on Nightly and 10~15 on Chrome 32.

Comment 77

[Olli Pettay [:smaug][[e-mail]]]

Yes, chromium is faster here.
We spend most of the time in setting those .style. properties. Parsing those values etc.

Comment 78

[Olli Pettay [:smaug][[e-mail]]]

Attachment: modified version of the initial testcae

This just runs the testcase attachment 9328 [details] in a loop. Easier to profile.

Comment 79

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 51 votes and 73 CCs.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 80

[Emilio Cobos Álvarez (:emilio)]

Testcase is faster in Nightly than other browsers for me. This bug title is very generic, specific problems should be filed in separate bugs, ideally with test-cases or profiles :)