The default bug view has changed. See this FAQ.

tracking performance of the DHTML test on http://www.e-gandalf.net/mozilla/bugs/140789/dynl-c31.html

NEW
Unassigned

Status

()

Core
Layout
15 years ago
4 years ago

People

(Reporter: Ronald van Kuijk, Unassigned)

Tracking

(Blocks: 1 bug, {perf, testcase})

Trunk
perf, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

15 years ago
This entry is to keep track of reports on the performance of
http://alladyn.art.pl/gandalf/MozillaTests/dynl.html. We can do this better here
than to spam all other bugs with new things, discussions etc...

My latest results (winXP, 1GHz/128MB)

Trunk 20020428

Creating 200 layers - time - 391
Moving 200 layers 100 px to left - time - 27509
Cliping 200 layers - time - 110
Setting Opacity 10% - time - 10055
Reverting z-index for 200 layers - time - 100
Moving with changing opacity and clip - time - 15753
Inputing text into 200 layers - time - 220
Resizing 200 layers - time - 140
-----------------------------------------

exp-129155  (based on 20020422)

Creating 200 layers - time - 591
Moving 200 layers 100 px to left - time - 5628
Cliping 200 layers - time - 151
Setting Opacity 10% - time - 13730
Reverting z-index for 200 layers - time - 140
Moving with changing opacity and clip - time - 22142
Inputing text into 200 layers - time - 311
Resizing 200 layers - time - 221
------------------------------------

IE 6.0

Creating 200 layers - time - 591
Moving 200 layers 100 px to left - time - 2914
Cliping 200 layers - time - 200
Setting Opacity 10% - time - 10626
Reverting z-index for 200 layers - time - 170
Moving with changing opacity and clip - time - 16824
Inputing text into 200 layers - time - 280
Resizing 200 layers - time - 260
(Reporter)

Comment 1

15 years ago
Christopher: 

Can you post your mac results here to and possibly try the experimental build
also (there is a mac version). It's good to include RC1 to so we can show the
improvement...)
 
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: petersen → rtvkuijk
Ronald, any chance of running that test with a 20020422 trunk build so that we
can tell whether the reflow branch actually causes any slowdowns?

Comment 3

15 years ago
Reposted from bug 21762:
I tried to run the alladyn tests on OS X, but I'm not sure I trust the numbers
its giving me. Specifically, the numbers seem to skew when the browser hangs
with the spinning rainbow/working cursor. The final test (resize) is the worse
in that the browser was hung for over 2 minutes (eyeballing an external clock)
and both times the number that was reported back was <1000. [The golfers on my
TV were moving faster]. Also, on none of the tests in moz or chimera did I see
any animating actually happening - only the the end results were actually painted.

Powerbook G4/400mhz/OS X 10.1.4/1GB ram

	RC1	Trunk*	Chimera	0.2.5	IE5.1.4
Test 1	2121	1509	1520		1239
Test 2	36442	37694	27431		9698
Test 3	349	298	304		134
Test 4	16031	13892	12740		3063**
Test 5	358	307	288		158
Test 6	32172	27940	26333		14590**
Test 7	841	626	544		hung
Test 8	813	646	hung (8+min)

* Trunk build was: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.0+)
Gecko/20020428
** These numbers may not be of much use in a comparison as IE/Mac doesn't
support opacities
Ok. My last results (Win2k,Athlon 700,392 ram):
Mozilla 2002042808

Creating 200 layers - time - 701
Moving 200 layers 100 px to left - time - 35881
Cliping 200 layers - time - 150
Setting Opacity 10% - time - 21500
Reverting z-index for 200 layers - time - 140
Moving with changing opacity and clip - time - 34670
Inputing text into 200 layers - time - 300
Resizing 200 layers - time - HANGED*

IE 6

Creating 200 layers - time - 660
Moving 200 layers 100 px to left - time - 3355
Cliping 200 layers - time - 190
Setting Opacity 10% - time - 15202
Reverting z-index for 200 layers - time - 160
Moving with changing opacity and clip - time - 25417
Inputing text into 200 layers - time - 410
Resizing 200 layers - time - 321

* - Mozilla hanged after i pressed "START" button for last test. Its 
process "eated" 99% of CPU for 1 minute - after this, i closed it.

Few notices:

During tests, You shouldn't blur window with tests, it should be visible on 
screen. Otherway it works much faster.
If You have lower resolution (800x600 or sth like this) and You dont see all 
layers, changing opacity and moving is much faster.

I'm making some tests to see if it's not JavaScript problem (performance of for
(),if() and with()) but as i see those commands works faster in Mozilla than 
IE :)
Chris: i dont belive JavaScript date object on OS X. Meaby this is the reason? 
Or meaby tests goes in this time, but after this something hangs?

Comment 6

15 years ago
Downloaded the experimental Mac build, but its an OS 9 build and not OS X.
Running the build in Classic mode (and its associated overhead) the numbers I
get follow. Overall drawing/painting of the animations are noticably better, but
I don't know if that can be attributed to the patches or other differences
between current OS9 vs. OS X perfomance.

Creating 200 layers - time - 1481
Moving 200 layers 100 px to left - time - 16927
Cliping 200 layers - time - 342
Setting Opacity 10% - time - 20107
Reverting z-index for 200 layers - time - 325
Moving with changing opacity and clip - time - 29353
Inputing text into 200 layers - time - 665
Resizing 200 layers - time - 608

Comment 7

15 years ago
My thought on the time issues is that there is some lag between the javascript
execution and painting. This isn't based on anything but a hunch. I'll try and
throw some tests together, but it may not be right away.
Next results: iMac OS 9

IE 5.01:

Creating 200 layers - time - 1600
Moving 200 layers 100 px to left - time - 5318
Cliping 200 layers - time - 193
Setting Opacity 10% - time - 3858 (didn't change opacity)
Reverting z-index for 200 layers - time - 166
Moving with changing opacity and clip - time - 12565
Inputing text into 200 layers - time - HANGED

Mozilla 2002042708

Creating 200 layers - time - 2049
Moving 200 layers 100 px to left - time - 36948
Cliping 200 layers - time - 439
Setting Opacity 10% - time - 2910
Reverting z-index for 200 layers - time - 440
Moving with changing opacity and clip - time - 36852
Inputing text into 200 layers - time - 845
Resizing 200 layers - time - HANGED

Humm, i dont know how Mac OS works, but:

 - in IE when it hanged there was black-white circle as a cursor
 - in Mozilla when it hanged there was clock.

Please, try newest nighlty builds. I'm afraid that there is some bug in 
Resizing. It hanged for me in both, Mac and Windows.

And last thing. When i runned Alladyn's page (http://alladyn.art.pl) animation 
was quite fast (much faster than in Windows version of Moz). Is it possible, 
that on Macintosh, Mozilla use more resurces but doesnt has performance bug?

Greets
Errata: On Mac, In Mozilla's results - Opacity changes taked 29106 miliseconds, 
not 2910.

Comment 10

15 years ago
Test results using RedHat Linux 7.1, 2.4.18
Athlon 1200
512MB
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020428 (from
CVS)--disable-tests --disable-debug

Creating 200 layers - time - 1457
Moving 200 layers 100 px to left - time - 27443
Cliping 200 layers - time - 371
Setting Opacity 10% - time - 11530
Reverting z-index for 200 layers - time - 371
Moving with changing opacity and clip - time - 26163
Inputing text into 200 layers - time - 663
Resizing 200 layers - time - 678
(Reporter)

Updated

15 years ago
Keywords: perf, testcase

Comment 11

15 years ago
Test results using win-xp,1.1ghz,512MB

trunk build 2002042903 (so with 129115 and 129953)!
In brakets are the results of MSIE6 - for comparison.


Creating 200 layers - time - 370 (421)
Moving 200 layers 100 px to left - time - 25279 (2424)
Cliping 200 layers - time - 100 (171)
Setting Opacity 10% - time - 10066 (8874)
Reverting z-index for 200 layers - time - 90 (140)
Moving with changing opacity and clip - time - 15453 (14361)
Inputing text into 200 layers - time - 210 (251)
Resizing 200 layers - time - 120 (221).

So in moving the layers we are still doing very badly.
Far to much painting seems to be the main reason. 

See in this regard
bug 107746, bug 139986, bug 87808



(Reporter)

Comment 12

15 years ago
Markus: are you sure the trunk build contains the patch from 129115? The figures
are from a 'normal' trunk build. On my system with the experimental build for
bug 129115 we are only 2x slower than IE, and 10x with the trunk)
(Reporter)

Comment 13

15 years ago
I noticed when running these thest on IE my CPU (PIII/800MHz) also jumps to
100%... anybody else noticed this?
Bug 129115 has not been checked in yet, so comment #11 is incorrect.
(Reporter)

Comment 15

15 years ago
Results on linux. Including the 'original' 20020422 build on which the '129115
build' was based. (On request of BZ)

PIII/899MHz/256MB/Linux 2.4.16/XFree4.2

                                         1)      2)      3)      4)
Creating 200 layers                      908     917     896     938
Moving 200 layers 100 px to left         21935   21912   22140   6363
Cliping 200 layers                       186     194     196     205
Setting Opacity 10%                      7624    7712    7730    7923
Reverting z-index for 200 layers         186     173     174     181
Moving with changing opacity and clip    15397   15696   15552   15961
Inputing text into 200 layers            379     N/T     383     402
Resizing 200 layers                      345     N/T     349     343

1) Mozilla 2002042221
2) Mozilla 20020426??
3) Mozilla 2002042910
4) Mozilla 20020422 with JS reflow patch ('exp-129115 build')

So on Linux there are no regresions caused by the patch in bug 129115 (and all
the ones this includes). So on windows they are probably related to some windows
only patches, since the times on the tests are lower (almost half) on windows
than they are on linux (for 'same' build versions) and almost same machine (100
MHz more for windows)

Another difference is that on windows during opacity changes there is always
something visible although it's flashing (IE does it smoothly) On Linux nothing
is drawn until a test finishes (just like on the mac).
(Reporter)

Comment 16

15 years ago
Gandalf: Perhaps you could make the same test with a background image in there.
Markus mentioned bug 87808 in comment 11.
I started work on much more complex test. I wanted to test JavaScript 
performance in first part, and DHTML in second. Each test is separately, but 
You can make whole part at once (this will show mem leaks too).

It should be ready tommorow. 

And following Ronald's ask - 
http://alladyn.art.pl/gandalf/MozillaTests/dynl2.html .

Greets

Comment 18

15 years ago
OK, I've done a more complete test series now on Linux.
Every test was done three times, and I'm giving the best-of-three numers here to
avoid that any background processes changed the results.
If you want, I can attch the complete results of all runs, I have them in a text
file.

System: PII-400/448MB RAM/Linux 2.4.18/X 4.2.0/ATI Mach64 Graphics

                                         RC1  dynl2  trunk1  trunk2  trunk2/p
Creating 200 layers                     1996   1994    1867    1965      2031
Moving 200 layers 100 px to left       27728  28089   27247   28421     17548
Clipping 200 layers                      394    368     345     406       407
Setting Opacity 10%                    16582  17630   15465   16928     16998
Reverting z-index for 200 layers         371    357     361     391       400
Moving with changing opacity and clip  32822  33435   31322   34774     34756
Inputing text into 200 layers            737    768     768     822       838
Resizing 200 layers                      737*   735*    705*    810*      776

the column topics mean the following:
RC1:      Linux RC1 default build
dynl2:    RC1 with dynl2 page (with a background image)
trunk1:   self-compiled, optimized trunk build with pull date 2002-05-01
trunk2:   same as trunk1, but pull date 2002-05-02
trunk2/p: same as trunk2, but patch from bug 129115 applied (Attachment #81952 [details] [diff])

*: note that I had to wait 3 Min with CPU at 100% until the number showed up and
I could proceed. The patched build works as expected here and is finished within
10 secs.

I'm not sure why performance of my build seems to have decreased from -05-01 to
-05-02 build but that's why I included both numbers.

The patch from 129115 seems to help a lot at moving (-40%) but doesn't really
affect the numbers of other tests though the whole rendering seemed more
smoothly - and that long waiting time after the last test is almost reduced to
zero, that's really cool!
Great improvment!!!!!!

Mozilla 2002051104 - 

Creating 200 layers - time - 731
Moving 200 layers 100 px to left - time - 7541 (!!!!!!!!!!!)
Clipping 200 layers - time - 140 (!!!!!!!!!!)
Setting Opacity 10% - time - 12148 (still bugged and slow)
Reverting z-index for 200 layers - time - 140 (!!!!!!!!!!)
Moving with changing opacity and clip - time - 35741 (the same speed)
Inputing text into 200 layers - time - 331 (!!!!!!!!!!!)
Resizing 200 layers - time - 310 (!!!!!!!!!!)

Really great!!!! What left? Combination - moving,clipping,opacity changing.

Greets

Comment 20

15 years ago
Also bug 75121 will be a major perf boost!
besides bug 123668, bug 107746, bug 139986, bug 87808, bug 115247

Comment 21

15 years ago
Dual Athlon XP 1700+, 1GB DDR266 RAM, Windows XP, GeForce2MX
                           trunk-2002051104  IE6.0  Moz/IE*100%
Creating 200 layers                     359    312  115%
Moving 200 layers 100 px to left       4437   2203  201%
Clipping 200 layers                      79     94   84%
Setting Opacity 10%                   10766*  6797  158%
Reverting z-index for 200 layers         47     78   60%
Moving with changing opacity and clip 16438  11265  146%
Inputing text into 200 layers           203    219   93%
Resizing 200 layers                     109    141   77%
*blinks
I think its interesting that my results are roughly half of Zbigniew Braniecki's
results, except for one case: the opacity test.  Especially since it blinks, I
wonder if there's something wrong with the opacity code.
I'm shure there is a bug in whole Mozilla with Opacity. Blinking is windows-
only problem, but on macintosh it sometimes crash during it, otherwise it dont 
set opacity at all.
I hope it'll be fixed next after we improved speed.
Mozilla trunk 2002052121 Linux RH7.3

Creating 200 layers - time - 808
Moving 200 layers 100 px to left - time - 5038
Clipping 200 layers - time - 160
Setting Opacity 10% - time - 6356
Reverting z-index for 200 layers - time - 163
Moving with changing opacity and clip - time - 12998
Inputing text into 200 layers - time - 344
Resizing 200 layers - time - 322

Next improvement...but on my 800x600 16 bit color deph, Opacity doesnt redraw
during animation.

Comment 24

15 years ago
For several weeks I'm freezing on "Setting Opacity 10%", lastly with 1.1a. (I
see opacity being applied layer by layer, but then suddenly all layers disapears
and the tab with test is frozen.) Anybody knows what's happening?

Comment 25

15 years ago
Probably it's related to the checkin of bug 124685.
Is it setting "10%" or "0.1"?  The former is much slower and does not do the
same thing as "0.1"....

Comment 27

15 years ago
For me, everything works. And here are the results (Note the different system
data compared to last time):

System: P4-1.8/512MB DDR333/Linux 2.4.18/X 4.2.0/NVidia GeForce2 MX-400

                                           1.0  trunk
Creating 200 layers                        634    611
Moving 200 layers 100 px to left         21426   3975
Clipping 200 layers                        150    147
Setting Opacity 10%                       5170   5147
Reverting z-index for 200 layers           137    133
Moving with changing opacity and clip    11244  10988
Inputing text into 200 layers              274    273
Resizing 200 layers                        276*   265

*: waiting a quite long time with 100% CPU until value is shown

"1.0" is official Mozilla 1.0 Linux final release
"trunk" is self-compiled gcc 2.95.3 2002-06-12 trunk build

All values are best-of-three-test-passes.

Unlike the most values may look, 1.0 *feels* much slower on that tests than
current trunk (note that bug 129115 is not in 1.0)
How did You gain such amazing results with Moving Layers???????? I'm cannot
belive. I have 8000 for this test on my Athlon 750, and You have 21000 on Your
P1-8 with Moz 1.0 and 3000 with Your own build... How its possible?????

Comment 29

15 years ago
gandalf:
1) 1.8 GHz is quite alot faster than 750 MHz (only comparing frequency here, not
architecture)
2) As I stated, Mozilla 1.0 doesn't have the patch to bug 129115 but current
trunk has, and moving layers was the one thing this patch really affected _a
lot_ (see other postings here).

Comment 30

15 years ago
Again some new results to keep track of eventual progress:

System: P4-1.8/512MB DDR333/Linux 2.4.18/X 4.2.0/NVidia GeForce2 MX-400

                                           1.0  1.0.1RC    trunk
Creating 200 layers                        634      672      679
Moving 200 layers 100 px to left         21426     4443     3889
Clipping 200 layers                        150      146      130
Setting Opacity 10%                       5170     5477     5333
Reverting z-index for 200 layers           137      141      137
Moving with changing opacity and clip    11244    11631    11092
Inputing text into 200 layers              274      301      277
Resizing 200 layers                        276*     285      258

*: waiting a quite long time with 100% CPU until value is shown

"1.0" is official Mozilla 1.0 Linux final release (see Comment #27)
"1.0.1RC" is Mozilla 1.0 release candidate (should be same as 1.0.1 final)
"trunk" is self-compiled gcc 2.95.3 2002-08-18 trunk build

All values are best-of-three-test-passes.
The "opacity" testcases use "percentage" opacity instead of "number" opacity. 
The latter is much faster, and there is unlikely to ever be any work to make the
former fast (since it's invalid per CSS3 anyway and should IMO be removed).

In short, I'd be interested in seeing the same numbers but for a correct usage
of opacity.
First - Mozilla 2002051104
Second - Mozilla 2002082308 
Creating 200 layers			- 731	- 822
Moving 200 layers 100 px to left	- 7541	- 6960
Clipping 200 layers 			- 140	- 160
Setting Opacity 10% 			- 12148	- 18757
Reverting z-index for 200 layers  	- 140	- 180
Moving with changing opacity and clip	- 35741	- 36543
Inputing text into 200 layers		- 331	- 351
Resizing 200 layers			- 310	- 320

With Comment #31 improvments.

Comment 33

15 years ago
gandalf, could you provide a file with comment #31 incorporated?
e.g. as dynl-c31.html
http://alladyn.art.pl/gandalf/MozillaTests/dynl-c31.html - ready.

Comment 35

15 years ago
Here are again some numbers of my system:

System: P4-1.8/512MB DDR333/Linux 2.4.18/X 4.2.0/NVidia GeForce2 MX-400

                                           1.0    1.0.1      1.1    trunk
Creating 200 layers                        634      894      633      650
Moving 200 layers 100 px to left         21426     4442     3838     4648
Clipping 200 layers                        150      140      127      151
Setting Opacity 10%                       5170    10121     5136     5234
Reverting z-index for 200 layers           137      138      131      164
Moving with changing opacity and clip    11244    16865    10881    12159
Inputing text into 200 layers              274      279      301      295
Resizing 200 layers                        276*     278      286      316

dynl-c31.html:
                                                  1.0.1      1.1    trunk
Creating 200 layers                                 862      632      642
Moving 200 layers 100 px to left                   4197     3697     4585
Clipping 200 layers                                 140      130      149
Setting Opacity 10%**                             16056    11085    10807
Reverting z-index for 200 layers                    146      130      167
Moving with changing opacity and clip**           26218    20067    21130
Inputing text into 200 layers                       273      275      288
Resizing 200 layers                                 267      253      422

*: waiting a quite long time with 100% CPU until value is shown
**: 6 to 10 steps are painted until finishing due to faster computation with
dynl-c31.html, dynl.html only renders the last step and so needs less rendering
time.

"1.0" is official Mozilla 1.0 Linux final release (see Comment #27)
"1.0.1" is Mozilla 1.0.1 Linux final release
"1.1" is Mozilla 1.1 Linux final release
"trunk" is self-compiled gcc 2.95.3 2002-09-19 trunk build

All values are, as usual, best-of-three-test-passes.
Yes. I see similar results wih Opacity. I'll try to find tim to create
standalone testcase for Opacity performance.

In first testcase, Image is drawen only once - in last frame.
In c31, Mozilla draws more frames, and it's slower.
Regressions in 2002092108

Creating 200 layers - time - 842
Moving 200 layers 100 px to left - time - 10004
Clipping 200 layers - time - 220
Setting Opacity 10% - time - 20429
Reverting z-index for 200 layers - time - 250
Moving with changing opacity and clip - time - 41930
Inputing text into 200 layers - time - 391
Resizing 200 layers - time - 1092

Most important is regression with Moving speed. But comparing with my results
from Comment 32 - everything is slowed down.

Comment 38

15 years ago
Regression reported in bug 169748 - seems overal moving is slowed down 
considerably - most probably due to bug 164931.

Note: The fix for bug 164931 forces each frame of the animation to be painted
before rendering the next frame on WIN32. Prior to this fix. Moves and other
animation could be done without painting the result after each change (Paint
starvation). For example, in somecases 1 out of every 3 frames would actually be
painted. This would produce a faster overall time on benchmarks, but it was a
false performance measurement.
Can anyone experiencing a slowdown please try pulling a 9/16 WIN32 build and
compare the 9/16 times against a 9/20 or later WIN32 build?  The fix for bug
164931 was checked in on 9/18. This would help isolate performance changes as a
result of the checkin for bug 164931.
Running http://alladyn.art.pl/gandalf/MozillaTests/dynl-c31.html on WinXP-pro
750Mhz AMD CPU I *don't* see any statistically significant difference between 
9/16 and 9/22 builds. Graphics card: ATI 3D Rage IIC AGP (Lowend $15 graphics
card) 8MB of video memory.

Using 9/16 build which is before bug 164931 checkin (2002091604) 

Creating 200 layers - time - 791
Moving 200 layers 100 px to left - time - 11146
Clipping 200 layers - time - 210
Setting Opacity 10% - time - 16914
Reverting z-index for 200 layers - time - 230
Moving with changing opacity and clip - time - 35261
Inputing text into 200 layers - time - 370
Resizing 200 layers - time - 861

Using 9/22 build after patch for bug 164931 landed (2002092208) build

Creating 200 layers - time - 801
Moving 200 layers 100 px to left - time - 10685
Clipping 200 layers - time - 210
Setting Opacity 10% - time - 16403
Reverting z-index for 200 layers - time - 220
Moving with changing opacity and clip - time - 35520
Inputing text into 200 layers - time - 351
Resizing 200 layers - time - 852


Does anyone see a significant difference between 9/16 and 9/22 builds?

Comment 42

15 years ago
dynl-c31.html: WinXP, Dual Athlon XP 1700+, 1GB DDR266 RAM, NVidia GeForce2MX
                                  2002092404 2002092408 IE 6.0.2800
Creating 200 layers                      390        375         281          
Moving 200 layers 100 px to left        5281       4953        1891
Clipping 200 layers                      109        109          78
Setting Opacity 10%                     9110       9031        6531
Reverting z-index for 200 layers         140        109          62
Moving with changing opacity and clip  19703      19031       10453
Inputing text into 200 layers            218        219         204
Resizing 200 layers                      656        656         125
It appears the patch for bug 75121 helped a little, but we're still a far cry 
from IE 6SP1.  It looks like they gave SP1 a perf boost.  Also, it seems that 
Mozilla performance has degraded since I last tested in May.  Every single 
test is slower than before, some by quite a bit.
I would be interested in finding out how much of this is due to painting and how
much due to reflow.

Could you repeat the tests with the browser window entirely off-screen (as much
as possible)?

Comment 44

15 years ago
roc:
On my Linux build, I can't see any significant differences in speed if I move
the re-painted parts of the page off screen. I still get the same numbers. It
seems actual painting either doesn't be the problem here, or Linux builds do no
optimization dependant on whether the painted area is acutally visible (which
would be really bad).
BTW, on a 2002-09-25 cvs build, I still see virtually the same numbers as in my
comment about the 2002-09-19 build.

Comment 45

15 years ago
I do not see any change when the window is off of the screen.  However, if I
make the window really small, there is a significant change.  The reason the
first test is higher is probably because of the scrollbar reflow.  I think we
can conclude that painting is a huge part of the time.  Now my question is, do
people see the same performance difference on an ATI gfx card?
                                 Full screen Tiny window
Creating 200 layers                      375         406          
Moving 200 layers 100 px to left        4953        1594
Clipping 200 layers                      109          62
Setting Opacity 10%                     9031        1672
Reverting z-index for 200 layers         109          62
Moving with changing opacity and clip  19031        5171
Inputing text into 200 layers            219         187
Resizing 200 layers                      656         141

Comment 46

15 years ago
When viewing resource:///res/samples/test13.html with latest trunk build the 
animation is extremely fast if
1) I resize the window so that the scrollbars have a fixed size
2) the animation is in a position that no scrollbars are needed

if there are scrollbars then things get considerably slower. what is that 
related to ?

Comment 47

15 years ago
I again did some numbers, comparing a Linux gcc-2.95 build with a gcc-3.2 build
and both builds on full screen and very tiny window.

System: P4-1.8/512MB DDR333/Linux 2.4.18/X 4.2.0/NVidia GeForce2 MX-400
dynl-c31.html:
                                       1.0.1    1.1     t1  t1/tw     t2  t2/tw
Creating 200 layers                      862    632    672    670    634    625
Moving 200 layers 100 px to left        4197   3697   4107   2972   4080   2867
Clipping 200 layers                      140    130    166    141    169    132
Setting Opacity 10%                    16056  11085  10893   2932  11016   2872
Reverting z-index for 200 layers         146    130    164    146    167    139
Moving with changing opacity and clip  26218  20067  19828   9043  20730   8841
Inputing text into 200 layers            273    275    273    262    269    247
Resizing 200 layers                      267    253    467    297    442    285

"1.0.1" is Mozilla 1.0.1 Linux final release (see Comment #35)
"1.1" is Mozilla 1.1 Linux final release (see Comment #35)
"t1" is self-compiled gcc-2.95.3 2002-10-01 trunk build
"t1/tw" is "t1" build with a tiny window (no repaints on visible area)
"t2" is self-compiled gcc-3.2 2002-10-02 trunk build
"t2/tw" is "t2" build with a tiny window (no repaints on visible area)

All values are, as usual, best-of-three-test-passes.

1) The /tw tests show that painting takes up lots of our time here
2) The gcc-3.2 build seems to be faster in all tests, as the /tw tests show. The
"normal" builds seems to be able to paint the process more often, and that
should be the cause for making the times worse on the bigger operations. In the
/tw tests, gcc-3.2 build is 1.5-6% faster in all tests, with 2-3% faster in the
bigger ones. The gcc-3.2 builds use exactly the same build options as the
gcc-2.95.3 ones did, though gcc-3.2 can provide even better optimization with
its newly available settings.
I was just testing the patch for bug 171830 on this testcase and I found
something rather interesting on the opacity test (the patch didn't really have
any major effec on any other tests).  The times I was seeing (current Linux
trunk build, PIII-733, 640MB of RAM, etc, etc) were something like:

Without patch:  9149
With patch: 56091

Now as you may imagine this worried me a little and I investigated more closely.
 Here is what I found:

1) The test is still using percentage opacity instead of number opacity.
2) Percent opacity changes cause us to reframe the div instead of just
   repainting it in the current code.
3) We reflow/paint the new frames lazily.
4) As a result, in the current test the divs all disappear once you start
   changing opacity and are not shown until you are done changing it.
5) My change made us handle percent opacity changes correctly.  With my change
   we paint the various intermediate stages between 90% and 10% opacity.  This
   is a rather slow process and takes a long time....
6) These results are consistent with those of comment 23 and comment 32 (the
   times in comment 32 are for "number" opacity, which _should_ have been being
   properly repainted).

In short, the number from the opacity test is useless unless you also
quantitatively describe the repainting behavior.
Blocks: 171830
Oh, I forgot.  If I apply the patch in bug 171830 and then change
nsStyleVisibility::CalcDifference to always return a FRAMECHANGE hint for
opacity differences then the time on that testcase drops back down to around
9000-some ms.  So it's definitely a FRAMECHANGE vs. VISUAL issue.

Comment 50

15 years ago
bz:
dynl-c31.html as listed in Comment #34 is the test with number opacity intead of
percentage. Comment #35 lists some comparison numbers between the two (and tells
that we're repainting more often with number opacity), and recent "tiny window"
test results also show that a lot of the time is spent painting.

It's always nice to see some of that real great work of you appearing ;-)
Robert, thanks!  Looks like on the test in comment 34 both my build and the
nightly do about the same.  Good to know.  ;)

Not painting as often with percent opacity, which comment 35 shows, is a bug,
pure and simple.
Boris. Thank You for what You're doing.
Shouldn't we create self bug for Opacity performance? I see this as separate
bug. Right?
Sure, feel free to file one if there isn't one already...
So an update on testing the patch in bug 171830 (if people care):

WITHOUT PATCH:
Creating 200 layers - time - 1174 1153 1195
Moving 200 layers 100 px to left - time - 8326 8627 8446
Cliping 200 layers - time - 310 310 311
Setting Opacity 10% - time - 8938* 8847* 8816*
Reverting z-index for 200 layers - time - 307 319 337
Moving with changing opacity and clip - time - 21116* 21031* 21022*
Inputing text into 200 layers - time - 512 509 509
Resizing 200 layers - time - 562 587 565

WITH PATCH:
Creating 200 layers - time - 1142 1143 1137
Moving 200 layers 100 px to left - time - 8635 8583 8652
Cliping 200 layers - time - 321 318 320
Setting Opacity 10% - time - 24867** 22199** 22133**
Reverting z-index for 200 layers - time - 325 297 292
Moving with changing opacity and clip - time - 42236** 40992** 41705**
Inputing text into 200 layers - time - 525 517 495
Resizing 200 layers - time - 575 565 567

*No repaints or reflows happen between opacity=100% and opacity=10% due to
 continuous reframing
**Repaints and reflows happen as opacity/position/clip change
Great... any other plans to regress DHTML performance???

Bz, do you have any idea, why there is so big difference?
On which test?

Comment 57

15 years ago
I believe on the test you posted. Values with patch are worse than witout...
Since people don't seem to want to read, I'll go through the tests one by one:

Creating 200 layers -- about the same with or without patch
Moving 200 layers 100 px to left -- a bit slower with patch because the divs are
  nearly empty.  If they have some content in them, it's faster.  See the
  comments in bug 171830.  This is what I call a useless non-real-world
  benchmark.  That said, with that patch in place this test can be much more
  heavily optimized.  Again, that will mostly affect divs with something
  actually inside them.
Cliping 200 layers[sic] -- this is slower for now, but the patch enables us to
  make maximal use of roc's changes to produce the right hint for that change
  (said changes have not yet landed).
Reverting z-index for 200 layers -- about the same (maybe faster with the patch)
Inputing text into 200 layers -- about the same
Resizing 200 layers -- about the same
Setting Opacity 10% and oving with changing opacity and clip -- did you read
  comment 48 and the footnotes in comment 54?  Current builds simply fail these
  tests. They simply do not display the divs as you change the style.  Fixing
  that involves a bit of a perf loss since you have to friggin' _show_
  something.  I suppose we could just skip running all that JS and immediately
  put up alerts for all the tests -- that would give us real nice times.

I'll let you go back to not measuring what you think you're measuring now.
Looks good bz :-). I hope we can land this soon.

Comment 60

15 years ago
The next round of tests, again including "tiny window" tests.

System: P4-1.8/512MB DDR333/Linux 2.4.18/X 4.2.0/NVidia GeForce2 MX-400
dynl-c31.html:
                                       1.0.1    1.1     t1  t1/tw     t2  t2/tw
Creating 200 layers                      862    632    634    625    641    673
Moving 200 layers 100 px to left        4197   3697   4080   2867   4147   2949
Clipping 200 layers                      140    130    169    132    157    134
Setting Opacity 10%                    16056  11085  11016   2872  11006   2935
Reverting z-index for 200 layers         146    130    167    139    165    146
Moving with changing opacity and clip  26218  20067  20730   8841  20581   8916
Inputing text into 200 layers            273    275    269    247    273    253
Resizing 200 layers                      267    253    442    285    456    286

"1.0.1" is Mozilla 1.0.1 Linux final release (see Comment #35)
"1.1" is Mozilla 1.1 Linux final release (see Comment #35)
"t1" is self-compiled gcc-3.2 2002-10-02 trunk build (see Comment #47)
"t1/tw" is "t1" build with a tiny window (no repaints on visible area)
"t2" is self-compiled gcc-3.2 2002-11-03 trunk build (see Comment #47)
"t2/tw" is "t2" build with a tiny window (no repaints on visible area)

All values are, as usual, best-of-three-test-passes.

1) Again, the /tw tests show the big amount of time we spend painting.
2) The numbers for the bigger tests in full window tests don't tell too much, as
the faster the code gets, the less painting cycles are "starved" (left out), and
as painting takes up a lot of time, the numbers often grow when we "starve" less
painting.
"Starving" is a good thing IHMO, but it makes those test numbers simply useless
- that's also what we see with bz's numbers.
Mozilla 20021210:

Creating 200 layers - time - 892
Moving 200 layers 100 px to left - time - 10215
Cliping 200 layers - time - 340
Setting Opacity 10% - time - 24025
Reverting z-index for 200 layers - time - 291
Moving with changing opacity and clip - time - 41430
Inputing text into 200 layers - time - 401
Resizing 200 layers - time - 541

Comparing to Comment #37 - only Resizing layers is faster :( Almost no progress
since september
Blocks: 21762

Updated

15 years ago
No longer blocks: 171830
Depends on: 171830, 186133

Comment 62

14 years ago
It's been some time, so here's another round of tests.

System: P4-1.8/512MB DDR333/Linux 2.4.18/X 4.2.0/NVidia GeForce2 MX-400
dynl-c31.html:
                                       1.0.1    1.1  1.2.1 121/tw  trunk   t/tw
Creating 200 layers                      862    632    915    926    842    865
Moving 200 layers 100 px to left        4197   3697   4268   3147   3960   2928
Clipping 200 layers                      140    130    169    142    165    129
Setting Opacity 10%                    16056  11085  16086   7637  15210   7118
Reverting z-index for 200 layers         146    130    166    147    162    133
Moving with changing opacity and clip  26218  20067  26732  14707  25258  13673
Inputing text into 200 layers            273    275    289    279    264    252
Resizing 200 layers                      267    253    478    304    432    281

"1.0.1" is Mozilla 1.0.1 Linux final release (see Comment #35)
"1.1" is Mozilla 1.1 Linux final release (see Comment #35)
"1.2.1" is Mozilla 1.2.1 Linux final release
"121/tw" is "1.2.1" build with a tiny window (no repaints on visible area)
"trunk" is self-compiled gcc-3.2 2002-12-29 trunk build
"t/tw" is "trunk" build with a tiny window (no repaints on visible area)

All values are, as usual, best-of-three-test-passes.

1) /tw tests: see Comment #60
2) It seems we regressed creating of elements and setting opacity quite badly
between 2002-11-03 and now, that regression also went into thge 1.2 branch, as
itr seems from 1.2.1 numbers. We already regressed in other categories between
1.1 and 2002-10-02 trunk, so that we see an overall regression from 1.1 to 1.2.1
and current trunk. Are there any bugs filed for those issues?
Better performance of current trunk build compared to 1.2.1 seems to be the
usual speedup due to gcc-3.2 vs. gcc-2.95, no other significant performance
improvements or regressions since 1.2.1 can be detected here.
Robert. Tests on 1.1 and 1.2.1 were made really on same machine??? Big, big
regression...
(Reporter)

Comment 64

14 years ago
Unfortunately there is a real regression which happend between 1.1 and 1.2.1

PIII/700MHz/256MB/Linux 2.4.19/XFree4.2.0/ATI Rage-128M2/dyn-c31.html

                                         1.1     1.2.1   Trunk/20030103 
Creating 200 layers                      1036    1093    1135
Moving 200 layers 100 px to left         6849    7540    7564
Cliping 200 layers                       207     327     322
Setting Opacity 10%                      25481   22888   22643
Reverting z-index for 200 layers         208     273     275
Moving with changing opacity and clip    36927   38958   39113
Inputing text into 200 layers            468     478     482
Resizing 200 layers                      418     916     882

Tested just now, so no 'old' results. My system was not busy with other tasks
So certainly a regression on clipping, z-index and resizing

Comment 65

14 years ago
about half of the 1.1=>1.2 regression in the clipping test occurred between
2002092921 and 2002100104, incdicating bug 113083 (which was supposed to improve
performance)

Comment 66

14 years ago
Created attachment 110680 [details]
testcase times from various trunk/release builds

All times are from a PII-450MHz with 392 MB RAM and a RIVA TNT card running
Linux.	Most builds were tested at least twice with the minimum time from each
test taken.

setting opacity seems to have regressed between 2002080708 and 2002080822,
although I did not see any relevant checkins.

clipping, reverting z-index and resizing regressed between 2002082404 and
2002082521, apparently due to bug 160936

moving regressed between 2002082904 and 2002083005, although nothing in that
window seemed relevant.

moving got a boost between 2002092221 and 2002092408, apparently due to bug
75121

as mentioned above, bug 113083 seems to have caused an additional regression in
clipping

creating layers and inputting text might have regressed a little, but there is
too much noise to narrow it down.

current trunk (2002010404) is about as fast as 1.2.1

Comment 67

14 years ago
The time-frame of the regression seems to correlate with the one seen in bug 
186133
Updating URL. We should test Opacity on float values instead percent. (basing on
my tests no difference, but Boris asked for...)

Andrew, amazing job done... thanks.

About Opacity. I think (as Boris mentioned) this regression is because Mozilla
started really changing opacity in every step.
But why clipping, reverting z-index and resizing regressed due too fix in
Opacity related bug???
Summary: tracking performance of the DTHML test on http://alladyn.art.pl/gandalf/MozillaTests/dynl.html → tracking performance of the DTHML test on http://alladyn.art.pl/gandalf/MozillaTests/dynl-c31.html
Because the fix that fixed opacity also fixes potential problems with those
properties.

We can get the performance back (and more) by fine-tuning the style change hints
for those properties. That's my job.
Athlon 1.8, 512 DDR, GeForce 4, Mozilla 20020217

Mozilla:
Creating 200 layers - time - 328 (!)
Moving 200 layers 100 px to left - time - 3469
Cliping 200 layers - time - 156
Setting Opacity 10% - time - 8406
Reverting z-index for 200 layers - time - 110
Moving with changing opacity and clip - time - 15391
Inputing text into 200 layers - time - 172 (!)
Resizing 200 layers - time - 219

IE6:
Creating 200 layers - time - 390
Moving 200 layers 100 px to left - time - 1843 (!)
Cliping 200 layers - time - 94 (!)
Setting Opacity 10% - time - 6141 (!)
Reverting z-index for 200 layers - time - 78 (!)
Moving with changing opacity and clip - time - 10469 (!)
Inputing text into 200 layers - time - 219
Resizing 200 layers - time - 141 (!)

Someone could check it for Linux,MacOS?

Comment 71

14 years ago
OK, after almost two months, another round of trunk tests.

System: P4-1.8/512MB DDR333/Linux 2.4.18/X 4.2.0/NVidia GeForce2 MX-400
dynl-c31.html:
                                         1.1  1.2.1 121/tw  trunk   t/tw
Creating 200 layers                      632    915    926    878    896
Moving 200 layers 100 px to left        3697   4268   3147   4252   3026
Clipping 200 layers                      130    169    142    160    137
Setting Opacity 10%                    11085  16086   7637  12735   7659
Reverting z-index for 200 layers         130    166    147    165    162
Moving with changing opacity and clip  20067  26732  14707  22359  14341
Inputing text into 200 layers            275    289    279    265    265
Resizing 200 layers                      253    478    304    465    301

"1.1" is Mozilla 1.1 Linux final release (see Comment #35)
"1.2.1" is Mozilla 1.2.1 Linux final release (see Comment #62)
"121/tw" is "1.2.1" build with a tiny window (no repaints on visible area)
"trunk" is self-compiled gcc-3.2 2003-02-21 trunk build
"t/tw" is "trunk" build with a tiny window (no repaints on visible area)

All values are, as usual, best-of-three-test-passes.

1) /tw tests: again, see Comment #60
2) The builds I took have been pulled just before branching for 1.3, so the
results should be very similar to 1.3 final - but built with gcc 3.2, of course.
3) Tiny window results look a bit regressed to my last trunk nightly tests, but
almost the same as 1.2.1; opacity changes seem to paint faster though, as we're
seeing improvements on normal opacity tests. Moving seems to have regresed a bit
since December though...
It would be good if someone could test with both today's and tomorrow's builds.
 The times are likely to be a bit slower due to bug 171830 landing; the question
is how much slower.
I'll do this tommorow for windows and MacOSX.
Someone could do it for Linux?

Comment 74

14 years ago
same system as described in comment 66, testing dynl-c31.html
                                      2003030605      -0705
Creating 200 layers                         2131       2364  +10%
Moving 200 layers 100 px to left           15096      16689  +10%
Clipping 200 layers                          525        640  +19%
Setting Opacity 10%                        56390      58830   +4%
Reverting z-index for 200 layers             487        580  +17%
Moving with changing opacity and clip      87637      93297   +6%
Inputing text into 200 layers                901        934   +3%
Resizing 200 layers                         1828       2018   +9%
Windows XP (GeForce4, Athlon 1.8)

----------------TEST------------------|--0306--|--0307--|--Diff--|
                                      |        |        |        |
Creating 200 layers                   |  296   |  328   | +09.8% |
Moving 200 layers 100 px to left      |  3094  |  3500  | +11.6% |
Clipping 200 layers                   |  125   |  140   | +10.7% |
Setting Opacity 10%                   |  6953  |  7187  | +03.3% |
Reverting z-index for 200 layers      |  94    |  109   | +13.8% |
Moving with changing opacity and clip |  13656 |  14984 | +08.9% |
Inputing text into 200 layers         |  156   |  156   |  00.0% |
Resizing 200 layers                   |  547   |  578   | +05.4% |
--------------------------------------|--------|--------|--------|

0306 - Mozilla trunk 2003030608
0307 - Mozilla trunk 2003030708

Boris, there's nothing we can do with this perf loose?
Well, now we try to use the new and better style resolution to reduce the amount
of work that needs doing.  ;)  The hope is that this will offset the loss that
bug 171830 caused and then some...

I do have some ideas on possibly reducing the cost of the reresolve itself (or
rather reducing the number of reresolves needed); I'll file a bug and make it
block this one when they're slightly more fleshed out ideas.

Thanks for testing, guys!  Something in the 10%-worst-case range is what I'd
been seeing too, and just wanted verification....
So I carefully read this test for the first time....  It executes totally
different code in IE and Mozilla, so I'm not sure why we're even bothering to
make the comparisons to IE.

Typical example:

function Step(){
  q=document.all?document.all:document.getElementsByTagName('div');
  for(i=0;i<200;i++){
    q['lay'+i].style.left=20+(i*3)+l;
  }
}

This does an O(N) lookup for each q['lay'+i] in Mozilla.  I have no idea what
document.all('lay'+i) does in IE, but I would not be at all surprised if it were
optimized to just call document.getElementById('lay'+i) or something (since
those two _are_ equivalent, whereas looking for elements with name/id 'lay'+i in
just the list of divs is not the same thing at all).

In any case, simply changing that to be:

function Step(){
  q=document.all?document.all:document.getElementsByTagName('div');
  for(i=0;i<200;i++){
    q[i].style.left=20+(i*3)+l;
  }
}

(and changing all the extraneous <div> tags to <p>) made the "move 200 divs" 20%
faster in Mozilla.  I'd be interested in seeing what the numbers look like if
that code just uses getElementByID, which is supported in a similar way by both
IE and Mozilla).

Of course comparing Mozilla to itself is still reasonable....
Boris, the trully reason for this code, was to make this test compatibile with IE4.

At now, when IE4 results are not interesting for us, i can change it.

But as I see, |all| is not only function, but also array document.all['value'],
isn't it? So we have similar situation array |all| and array of results for
getElementsByTagName('div')... even IE should be slower due too this. Because
document.all contains all identified elements, and in Mozilla's part we have
only DIV elements.

I'd not change 'div' to 'p' because most of work with animations people do with
DIV element, and this is our start point to test differences in performance.


You want me to replace with Your code, or to use DOM's getElementById for this?
And is this only change You want?
If you say "give me an element with this name" (the document.all path) then it's
trivial to do a hashtable lookup.  If you say "give me all elements with this
tagname" and then "give me the element from this list that has this name", the
second operation has to walk the list to find the element.  Or it can do the
hashtable lookup as it would for the first case, then walk the list to make sure
it's in the list.

So in fact getting "the div with name 'foo'" is a lot slower than "the element
with name 'foo'".

I was referring to the <div>s that are part of the test harness.  So you still
_animate_ the divs, but the elements that say what test is being done are <p>.
Then you don't have to worry about whether the div you want is one that you need
to animate or not.

I don't really want anything, other than to not compare to IE unless we're at
least executing comparable code (createElement is even worse as far as this goes
-- the IE code and Mozilla code there have nothing to do with each other).

So you could change nothing, as long as we compare Mozilla to Mozilla only.  But
a high fraction of the cost are things that are not worth optimizing, imo, since
they would not come up in any sane DHTML setup.
Ok. As far as I'm sure we have to compare our results with IE, i'm going to
rebuild tests with excluding NS4/IE4 parts, implement Boris suggestions, add few
tests more (like simplest Drag&Drop) and build better interface.
Could people also test how the fix for bug 196603 affected perf?  (It should be
either nothing or a slight worsening of perf...)

Comment 82

14 years ago
OK, after almost two months, another round of trunk tests.

System: P4-1.8/512MB DDR333/Linux 2.4.18/X 4.2.0/NVidia GeForce2 MX-400
dynl-c31.html:
                                         1.1  1.2.1    1.3  t/1.3 t/1.4a
Creating 200 layers                      632    915    947    878    954
Moving 200 layers 100 px to left        3697   4268   4478   4252   4727
Clipping 200 layers                      130    169    177    160    193
Setting Opacity 10%                    11085  16086  17049  12735  16256
Reverting z-index for 200 layers         130    166    171    165    191
Moving with changing opacity and clip  20067  26732  27981  22359  27293
Inputing text into 200 layers            275    289    290    265    268
Resizing 200 layers                      253    478    494    465    533

tiny window (no repaints on visible area):
                                              1.2.1    1.3  t/1.3 t/1.4a
Creating 200 layers                             926    946    896    971
Moving 200 layers 100 px to left               3147   3236   3026   3600
Clipping 200 layers                             142    147    137    166
Setting Opacity 10%                            7637   7951   7659   7547
Reverting z-index for 200 layers                147    152    162    177
Moving with changing opacity and clip         14707  15347  14341  15504
Inputing text into 200 layers                   279    278    265    260
Resizing 200 layers                             304    321    301    356

"1.1" is Mozilla 1.1 Linux final release (see Comment #35)
"1.2.1" is Mozilla 1.2.1 Linux final release (see Comment #62)
"1.3" is Mozilla 1.3 Linux final release
"t/1.3" is self-compiled gcc-3.2 2003-02-21 (1.3 branch time) trunk build (see
Comment #71)
"t/1.4a" is self-compiled gcc-3.2 2003-03-17 ("1.4a") trunk build

All values are, as usual, best-of-three-test-passes.

1) I've seperated normal from tiny window tests this time, to be able to comapre
numbers of more builds. Tiny window tests: again, see Comment #60
2) the t/1.3 vs. 1.3 final shows again the significant difference from
gcc-2.95.x to gcc-3.2 builds
3) As expected by comment #72, comment #76,and comment #81, we're seeing big
regressions since 1.3 - we're even worse than the gcc-2.95.x-built final
releases now...
4) Comparing to 1.1 final (and that's gcc-2.95.x as well), we've been doing a
great job at improving perf for inserting text in the <div>s. We've been doing
an even better job at regressing perf for all the other tests though. Perhaps we
may see some long-term improvement from all those changes, but currently we're
in the worst state since 1.1 (perf-wise), that's for sure.

Comment 83

14 years ago
re Comment #82, first line: it's been a bit less than 1 month. damn copy & paste
thing.

Comment 84

14 years ago
> Could people also test how the fix for bug 196603 affected perf?

                                      2003031505      -1605
Creating 200 layers                         2519       2476   -2%
Moving 200 layers 100 px to left           17289      16807   -3%
Clipping 200 layers                          627        629    0%
Setting Opacity 10%                        47651      36368  -24%
Reverting z-index for 200 layers             594        588   -1%
Moving with changing opacity and clip      81512      70272  -14%
Inputing text into 200 layers                936        920   -2%
Resizing 200 layers                         1991       2027   +2%

> (It should be either nothing or a slight worsening of perf...)

I think we can handle it.  ;)
Um.  Ok.... Now I'm a little confused, but..... ;)

Comment 86

14 years ago
I retested again this morning to make sure no demons had been inhabitting my
computer last night.  Apparently they were (I got much better times for some of
the tests (moving & opacity), others were not much different).  In fact
retesting 0315 build AGAIN gave even better times.  These are times after it
seems to have levelled off.  I'm so confused.

                                      2003031505      -1605
Creating 200 layers                         2489       2476    0%
Moving 200 layers 100 px to left           16441      16357   -1%
Clipping 200 layers                          618        611   -1%
Setting Opacity 10%                        24510      25244   +3%
Reverting z-index for 200 layers             566        584   +3%
Moving with changing opacity and clip      55465      56585   +2%
Inputing text into 200 layers                936        920   -2%
Resizing 200 layers                         1991       2027   +2%

(note that opacity is now very fast compared to comment 74)

Comment 87

14 years ago
I got a small upgrade of my system, and now I tried those tests again.

System: P4-1.8/512MB DDR333/Linux 2.4.21(pre)/X 4.3.0/NVidia GeForce2/MX-400
System (* - old): same, but Linux 2.4.18/X 4.2.0

dynl-c31.html:
                                        1.1*   1.3*  1.3.1 t/1.4a* t/1.5a
Creating 200 layers                      632    947    879     954    864
Moving 200 layers 100 px to left        3697   4478   4346    4727   4767
Clipping 200 layers                      130    177    164     193    170
Setting Opacity 10%                    11085  17049  14272   16256  15585
Reverting z-index for 200 layers         130    171    161     191    160
Moving with changing opacity and clip  20067  27981  24630   27293  25680
Inputing text into 200 layers            275    290    275     268    244
Resizing 200 layers                      253    494    507     533    495

tiny window (no repaints on visible area):
                                               1.3*  1.3.1 t/1.4a* t/1.5a
Creating 200 layers                             946    893     971    871
Moving 200 layers 100 px to left               3236   3362    3600   3170
Clipping 200 layers                             147    142     166    142
Setting Opacity 10%                            7951   7449    7547   7504
Reverting z-index for 200 layers                152    147     177    145
Moving with changing opacity and clip         15347  14626   15504  14407
Inputing text into 200 layers                   278    258     260    233
Resizing 200 layers                             321    296     356    305

"1.1*" is Mozilla 1.1 Linux final release (see Comment #35, "old" System)
"1.3*" is Mozilla 1.3 Linux final release (see Comment #82, "old" System)
"1.3.1" is Mozilla 1.3.1 Linux final release
"t/1.4a*" is self-compiled gcc-3.2 2003-03-17 ("1.4a") trunk build (see
Comment #82, "old" System)
"t/1.5a" is self-compiled gcc-3.3 2003-06-04 ("1.5a") trunk build (w/Xft support)

All values are, as usual, best-of-three-test-passes.

1) It's not easy to make any conclusions based an that data. Comparing 1.3 to
1.3.1 final, it seems my new kernel/X-Server combination does things faster, as
there were no perf improvements in Mozilla code there.
2) It seems that the 1.4 release cycle lost some performance comparing 1.3.1 to
current trunk, as the compiler does much faster builds but the numbers didn't
decrease that much.
3) The improvements from 1.4a trunk to current trunk could be again
kernel/X-related, but could additionally be some smaller Mozilla speedups as well
4) Still nothing can beat 1.1 in perf terms.

Comment 88

14 years ago
I do hope that bug 169770 will be really in very soon to better track down 
perf (regressions).
Comparing current values to where we already where (1.1) it's somewhat scary 
but I hope that it won't take not many more milestones to achieve that.
I'd also like to note that 1.1 had a number of correctness bugs that were fixed
by these perf regressions.  Which was at least some of the motivation for making
those changes...

Comment 90

14 years ago
bz: do you think we will get close to these values (1.1) with 1.5a ?
[there are a few patches waiting for release of 1.4final and there is some 
very promising arch work going on from you and dbaron]
Probably not with 1.5a.  With 1.6a, maybe. It's hard to get close to numbers
produced by incorrectly working code... ;)

Updated

14 years ago
Summary: tracking performance of the DTHML test on http://alladyn.art.pl/gandalf/MozillaTests/dynl-c31.html → tracking performance of the DHTML test on http://alladyn.art.pl/gandalf/MozillaTests/dynl-c31.html
It looks like dbaron just landed the patch for bug 125246.  Would someone be so
kind as to compare today's morning build to tomorrow morning's to see how it
affects things?
Sorry for delay:
WinXP Athlon 1.8Ghz 512 DDR GeForce 4 440

					07-04	08-04	diff
Creating 200 layers			- 359	328	+0.6%
Moving 200 layers 100 px to left	- 3453	3235	+6.3%
Clipping 200 layers			- 156	156	+0.0%
Setting Opacity 10%			- 6047	5937	+1.8%
Reverting z-index for 200 layers	- 125	125	+0.0%
Moving with changing opacity and clip	- 13843	13297	+3.9%
Inputing text into 200 layers		- 172	157	+8.7%
Resizing 200 layers			- 640	609	+4.8%

Nice.
(Reporter)

Comment 94

14 years ago
shouldn't 'creating 200...' also be 6%?

nice numbers indeed
btw, more stuff is happening in bug 188803; once the second patch lands people
may want to test again...
to comment #94. Yes. Of course, it should be even 8.6% boost! My mistake.

Boris, just post here info when You'll want it. If deeper tests are welcome, i
can check Mac and Linux too.
OK.  So the first part of the bug 188803 patch landed on "2003-06-17 18:59
-0700" and the second part landed on "2003-06-23 22:38/40 -0700".  So comparing
a June 16 or morning of June 17 build to one from June 24 would be nice.

Comment 98

14 years ago
I got a small upgrade of my system, and now I tried those tests again.

System: P4-1.8/512MB DDR333/Linux 2.4.21/X 4.3.0/NVidia GeForce2/MX-400

dynl-c31.html:
                                         1.3.1  t/0604  t/0624
Creating 200 layers                        879     864     819
Moving 200 layers 100 px to left          4346    4767    4679
Clipping 200 layers                        164     170     163
Setting Opacity 10%                      14272   15585   15315
Reverting z-index for 200 layers           161     160     156
Moving with changing opacity and clip    24630   25680   25722
Inputing text into 200 layers              275     244     248
Resizing 200 layers                        507     495     480

tiny window (no repaints on visible area):
                                         1.3.1  t/0604  t/0624
Creating 200 layers                        893     871     823
Moving 200 layers 100 px to left          3362    3170    2916
Clipping 200 layers                        142     142     140
Setting Opacity 10%                       7449    7504    7474
Reverting z-index for 200 layers           147     145     139
Moving with changing opacity and clip    14626   14407   14041
Inputing text into 200 layers              258     233     230
Resizing 200 layers                        296     305     291

"1.3.1" is Mozilla 1.3.1 Linux final release (see Comment #87)
"t/0604" is self-compiled gcc-3.3 2003-06-04 ("1.5a") trunk build (w/Xft
support, see Comment #87)
"t/0624" is self-compiled gcc-3.3 2003-06-24 ("1.5a") trunk build (w/Xft support)

All values are, as usual, best-of-three-test-passes.

1) It would have been nice to have a 1.4 final at hand as another comparison but
it might be somewhere between 1.3.1 and 0604 trunk.
2) The data looks as if there's a slight perf improvement from 06-04 to 06-24 in
almost all areas! It's not much in most areas, but it's nice to see!

Comment 99

14 years ago
Any idea why the test "Moving 200 layers 100 px to left" has regressed resp. 
is there ongoing work to get back to better values?
Yes.  It's regressed because the code is somewhat more optimized for moving
layers for something _in_ them now.  It's slower than it used to be for moving
completely empty divs.

There is no point optimizing specific testcases until the general arch work is
done.  I'm just trying to track the general impact of various arch changes so
that when the time comes to consider optimizing we'll have an idea of where to look.

Comment 101

14 years ago
Oh, fine.
Filed bug 210525 for another quite interesting test-suite to keep track of.
Athlon 1.8 Ghz, 512 DDR, WinXP, GeForce 4
					17-06	24-06	diff
Creating 200 layers			- 328	312	+4.9%
Moving 200 layers 100 px to left	- 3250	3250	+0.0%
Clipping 200 layers			- 156	141	+9.6%
Setting Opacity 10%			- 5938	5890	+0.8%
Reverting z-index for 200 layers	- 109	125	-14.6%
Moving with changing opacity and clip	- 13391	13109	+2.1%
Inputing text into 200 layers		- 156	156	+0.0%
Resizing 200 layers			- 625	609	+2.6%

All tests are "best of 3".
About regression in z-index. It was probably 'good luck' in my tests, because my
results in this one in Mozilla's build from 17th were: 125,127,109.
Re: bz's comment #100 -- I will go further, and say we should never optimize one
synthetic benchmark if it has nothing to do with real-world workloads.  Who
moves empty divs?  The assumption that empty-div-moving perf predicts
non-empty-div-... is not well founded.

Can we get a better synthetic benchmark to track?

/be
Brendan: empty divs are very nice blocks of colour, and can be used in any
animations.

But at all i agree, it's far more important to have good performance of filled
divs. You want me to change 200 empty DIVs into 100 DIVs with text and 100 DIVs
with images?
How about 4 (or 5) separate tests? 

1)  empty divs
2)  divs with text
3)  divs with images
4)  divs with a table containing 2-3 rows, a few columns, some text, etc.
maybe 5) divs with text and divs with images
No problem, DIVs with images - gif(animated?),png,jpg,mixed?
I doubt that it matters much, really... If we decide it does, the answer would
have to be "all of the above"  ;)

Comment 108

13 years ago
What are the numbers with a recent build?

Comment 109

13 years ago
Markus: some of the testcases are part of tinderboxen's Tdhtml (there's more
info somewhere, but I can't find it right now)
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey
http://axolotl.mozilla.org/graph/query.cgi?testname=dhtml&tbox=luna.mozilla.org&autoscale=1
Ouch. I lost that file (thanks God for webarchive.org!)

Linux - Slackware 10, Athlon 1.8 Ghz (same machine as previous results)

Firefox 1.0PR (20040914)

Creating 200 layers - time - 339
Moving 200 layers 100 px to left - time - 2467
Clipping 200 layers - time - 123
Setting Opacity 10% - time - 20171
Reverting z-index for 200 layers - time - 103
Moving with changing opacity and clip - time - 7251
Inputing text into 200 layers - time - 172
Resizing 200 layers - time - 296
Summary: tracking performance of the DHTML test on http://alladyn.art.pl/gandalf/MozillaTests/dynl-c31.html → tracking performance of the DHTML test on http://www.e-gandalf.net/mozilla/bugs/140789/dynl-c31.html
Can you test a trunk build, please?  Testing branch for DHTML performance is
pretty pointless by now.
Roger, roger sir! :)

Firefox trunk nightly (20041028) - similar machine, and configuration and OS

Creating 200 layers - time - 270
Moving 200 layers 100 px to left - time - 2368
Clipping 200 layers - time - 46
Setting Opacity 10% - time - 25240
Reverting z-index for 200 layers - time - 55
Moving with changing opacity and clip - time - 28448
Inputing text into 200 layers - time - 164
Resizing 200 layers - time - 86
in trunk test the better part was that the animation was animation rather than a
2 frame slide show - with first and last frame.
OK. Sounds like we're not doing too badly then (the non-animation testcase times
are way down from the branch numbers).
Same machine - Windows XP

Firefox (20041029) nightly trunk:

Creating 200 layers - time - 219
Moving 200 layers 100 px to left - time - 1422
Clipping 200 layers - time - 31
Setting Opacity 10% - time - 26438
Reverting z-index for 200 layers - time - 31
Moving with changing opacity and clip - time - 33047
Inputing text into 200 layers - time - 109
Resizing 200 layers - time - 47

IE 6:

Creating 200 layers - time - 328
Moving 200 layers 100 px to left - time - 1546
Clipping 200 layers - time - 78
Setting Opacity 10% - time - 6406
Reverting z-index for 200 layers - time - 78
Moving with changing opacity and clip - time - 10860
Inputing text into 200 layers - time - 203
Resizing 200 layers - time - 156

Opera 7.60 preview 2:

Creating 200 layers - time - 297
Moving 200 layers 100 px to left - time - 906
Clipping 200 layers - time - 16
Setting Opacity 10% - time - 297
Reverting z-index for 200 layers - time - 0
Moving with changing opacity and clip - time - 1641
Inputing text into 200 layers - time - 469
Resizing 200 layers - time - 15

Of course Opacity does not work here. The "0" time is probably a bug in Opera js .
Oh, wow.  I didn't realize we were actually faster than IE for a bunch of this
stuff now.  ;)  Opacity is the one exception, I guess.  Could someone file a
separate bug on that and cc me, please?   A testcase I can profile would help
there; somehow the opacity test didn't make it into our DHTML tests; perhaps it
should be added...

I know we're a bit slower than Opera 7.5+ on a lot of this stuff (though as the
comment noted a lot of the tests are comparing apples and oranges). I'm sorta
keeping an eye on that.
This is great news.

Opacity is probably just because of our really slow implementation of opacity
painting. Out of curiosity, do the translucent elements have a solid background
color?

To really kick butt on opacity we need the whole
Gfx-on-Cairo-on-GLitz-on-modern-hardware stack.
Boris: at the moment i found bug 179155, bug 166932, bug 193849 and bug 207146
related to slow opacity. Should i fill the one with reduced testcase for opacity?

Also i'd like to mention that the test with movement looks a way smoother in
both Opera and IE than in Gecko.

In other tests we rox :)
Ah, no.  If we already have bugs on opacity, no point to filing another one.  ;)
Just an update for AMD Sempron 2500+, Gentoo, between lastest 1.8 and 1.9

Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.8b4) Gecko/20050828 Firefox/1.0+

Creating 200 layers - time - 295
Moving 200 layers 100 px to left - time - 1643
Clipping 200 layers - time - 45
Setting Opacity 10% - time - 19316
Reverting z-index for 200 layers - time - 46
Moving with changing opacity and clip - time - 23625
Inputing text into 200 layers - time - 187
Resizing 200 layers - time - 85

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050912 Firefox/1.6a1

Creating 200 layers - time - 280
Moving 200 layers 100 px to left - time - 1298
Clipping 200 layers - time - 25
Setting Opacity 10% - time - 30134
Reverting z-index for 200 layers - time - 22
Moving with changing opacity and clip - time - 37276
Inputing text into 200 layers - time - 179
Resizing 200 layers - time - 35

Let me just point out that it seems that we're faster, but we're much (??)
slower in opacity.
Overall, we're very slow there (so nothing has changed)... None of the bugs that
could help us here was resolved :(
Zbigniew, can you possibly narrow down when we got slower on the opacity test? 
If there was a specific checkin that caused a perf regression, then we should be
able to fix it...
Well, I tried to , but it seems that it's already fixed :)

Diff between Fx 1.5 and trunk + Roc's patch (bug 317375) is impressive:

                                               Firefox 1.5     Trunk
Creating 200 layers - time -                   322             334
Moving 200 layers 100 px to left - time -      2074            1338
Clipping 200 layers - time -                   58              36
Setting Opacity 10% - time -                   18788           8327
Reverting z-index for 200 layers - time -      50              32
Moving with changing opacity and clip - time - 24607           15615
Inputing text into 200 layers - time -         198             163
Resizing 200 layers - time -                   99              44

I'm not sure how much Roc's patch influences it, but I'll test it soon. Anyone with numbers from Windows/Mac?
> I'm not sure how much Roc's patch influences it

I'd expect a good bit, since it does much more efficient display list optimization.
There was a bug in the patch in 317375, which I have just posted a fix for, which caused the text children to not be displayed from the "Setting Opacity 10%" step onward. This will have artificially improved the results from those steps, so we'll need to retest with the new patch. The results for the first three steps are still valid, I think.
With the fixed build (yup, it fixes the bug):

Creating 200 layers - time - 320
Moving 200 layers 100 px to left - time - 1288
Clipping 200 layers - time - 31
Setting Opacity 10% - time - 9223
Reverting z-index for 200 layers - time - 22
Moving with changing opacity and clip - time - 16275
Inputing text into 200 layers - time - 155
Resizing 200 layers - time - 43

So it's still way faster around Opacity and move than in 1.5!
I'm going to test diff between this build and clean trunk one.
Fx 1.5 vs Trunk vs Trunk+Roc's patch


                                        Fx 1.5     Trunk     Trunk+patch
-------------------------------------------------------------------------------
Creating 200 layers                     308        315       316
Moving 200 layers 100 px to left        2000       1217      1221
Clipping 200 layers                     50         23        22
Setting Opacity 10%                     18308      18235     9097
Reverting z-index for 200 layers        50         24        22
Moving with changing opacity and clip   24234      23051     16275
Inputing text into 200 layers           173        164       150
Resizing 200 layers                     103        40        41

Testing machine
Athlon 1.8 Ghz, 512 MB Ram, Gentoo, GeForce 6600GT.
One more comparsion sheet

                                        Trunk+patch   Opera 9.0P1   Konq 3.5
-------------------------------------------------------------------------------
Creating 200 layers                     316           52            91
Moving 200 layers 100 px to left        1221          1493          31207
Clipping 200 layers                     22            8             45
Setting Opacity 10%                     9097          MISS          MISS
Reverting z-index for 200 layers        22            6             42
Moving with changing opacity and clip   16275         MISS          MISS
Inputing text into 200 layers           150           10            65
Resizing 200 layers                     41            12            86

Notes: The most impressive thing about Opera's performance that beside of last two tests, it really displayed the result at the time (last two tests were displayed with delay comparing to time counter finish in all browsers). Amazing win over Fx in z-index revert, clip and new layers.
Created attachment 307700 [details]
testcase

Windows XP, from today (2 years later) :)

                                        Fx3b4pre  Fx2   IE7
-------------------------------------------------------------------------------
Creating 200 layers                     36        63    125
Moving 200 layers 100 px to left        356       594   937
Clipping 200 layers                     5         16    47
Setting Opacity 10%                     545       1843  2875
Reverting z-index for 200 layers        5         16    47
Moving with changing opacity and clip   1141      2843  5031
Inputing text into 200 layers           22        32    78
Resizing 200 layers                     10        32    78

Comment 129

9 years ago
Just for the fun of it, my current results for attachment 307700 [details]:

                   t/dbg trunk  brch 1.8.0   FF2
Creating...          190    54    82    98    74
Moving...           1167   423   620   691   610
Clipping...           25     8    19    22    20
Opacity 10%         1015   515  3284  2650  2884
Rev. z-index...       25     8    19    22    18
Mv. w/ opacity+clip 2652  1102  4473  4204  4411
Inp. text...          55    23    42    53    40
Resizing...           49    14    36    41    34


All numbers are best of 3 test runs.

System:
Core2Duo-2.4GHz/2GB DDR2-800/Linux 2.6.24/X.org 1.4.0.90/NVidia GF 7600 GT

t/dbg:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008030612 SeaMonkey/2.0a1pre
self-compiled DEBUG build

trunk:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008030612 SeaMonkey/2.0a1pre
self-compiled

brch:
Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.1.13pre) Gecko/20080305 SeaMonkey/1.1.9pre
self-compiled

1.8.0:
Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.12) Gecko/20070510 SeaMonkey/1.0.9
release build

FF2:
Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.12) Gecko/2008020300 SUSE/2.0.0.12-8 Firefox/2.0.0.12
openSUSE FACTORY 11.0 package


This might explain why I'm easily able to use that trunk debug build for production :)
Comparing performance to IE7 is not that useful nowadays. How do Opera and Safari do?
Comparing to IE7 is very useful, IMO -- that's where the users are that we're most trying to convert.  It's not the only useful comparison, to be sure, but we shouldn't neglect it in our tracking.
Maybe I should be clearer.  We're generally faster than IE7 at this point.  We're generally slower than Opera/Safari on this sort of workload.  So comparing _only_ to IE7 will usually not tell us much.
well, please, bare in mind that this testcase represents how js should not be used, but often is ;)

                                        Fx3b5pre  Op9.5b  WebKit nightly
-------------------------------------------------------------------------------
Creating 200 layers                     71        47      32
Moving 200 layers 100 px to left        786       1562    1734
Clipping 200 layers                     13        0       0
Setting Opacity 10%                     1072      797     3250
Reverting z-index for 200 layers        14        15      0
Moving with changing opacity and clip   2531      1906    5703
Inputing text into 200 layers           57        0       0
Resizing 200 layers                     25        0       16


the results for Opera and WebKit are misleading. In those "less than 50 ms" tests it took longer, but the result did not catch that. For Firefox the result was presented after the redraw happened always.
Created attachment 308853 [details]
same as above but with 400 divs

oh, forgot to say, the above results are for 400 divs instead of 200. It's just more visible then. Attaching
QA Contact: mozilla → layout
(Reporter)

Updated

6 years ago
Assignee: mozilla → nobody

Comment 135

5 years ago
                                      Firefox 17    Firefox 19      Difference
--------------------------------------------------------------------------------
Creating 200 layers -                    47             68           45% slower
Moving 200 layers 100 px to left -      896            2569         187% slower
Clipping 200 layers -                    11             18           64% slower
Setting Opacity 10% -                   942            1805          91% slower
Reverting z-index for 200 layers -       10             18           80% slower
Moving with changing opacity and clip - 11824          5343          55% faster
Inputing text into 200 layers -          17             14           18% faster
Resizing 200 layers -                    17             40          135% slower

Windows 7, D3D10
You need to log in before you can comment on or make changes to this bug.