Closed Bug 140789 Opened 23 years ago Closed 3 years ago

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

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Project Flags:
Performance Impact low

People

(Reporter: mozilla, Unassigned)

References

(
URL
)

Details

(Keywords: perf, perf:responsiveness, testcase)

Attachments

(3 files)

testcase times from various trunk/release builds
2.35 KB, text/plain
Details
testcase
7.07 KB, text/html
Details
same as above but with 400 divs
7.43 KB, text/html
Details
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
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?
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?
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
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.
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
Keywords: perf, testcase
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
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)
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.
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).
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
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
Also bug 75121 will be a major perf boost! besides bug 123668, bug 107746, bug 139986, bug 87808, bug 115247
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.
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?
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"....
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?????
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).
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.
gandalf, could you provide a file with comment #31 incorporated? e.g. as dynl-c31.html
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.
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?
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)?
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.
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
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 ?
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.
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?
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.
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
No longer blocks: 171830
Depends on: 171830, 186133
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...
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
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)
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
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???
URL: http://alladyn.art.pl/gandalf/Mozilla... → http://alladyn.art.pl/gandalf/Mozilla...
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?
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?
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...)
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.
re Comment #82, first line: it's been a bit less than 1 month. damn copy & paste thing.
> 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..... ;)
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)
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.
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...
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... ;)
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.
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.
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!
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.
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" ;)
What are the numbers with a recent build?
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
URL: http://alladyn.art.pl/gandalf/Mozilla... → http://www.e-gandalf.net/mozilla/bugs...
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.
Attached file 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
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.
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
Assignee: mozilla → nobody
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

ryzen 7 3600, win10
Summary: most of these are Very Fast now. On the 3 that aren't Firefox is about 50% slower than Chrome release. (Nightly is a little slower than late-beta or release, but not anywhere near 50%).

Very interestingly, if I turn on the profiler and run the test, Firefox is as fast as Chrome. This makes me think it has something to do with the Windows timer resolution setting (the profiler causes that to be bumped to a higher frequency).

Firefox Nightly 95.0a1 2021/10/20
Creating 200 layers - time - 2
Moving 200 layers 100 px to left - time - 308
Clipping 200 layers - time - 1
Setting Opacity 10% - time - 286
Reverting z-index for 200 layers - time - 2
Moving with changing opacity and clip - time - 315
Inputing text into 200 layers - time - 1
Resizing 200 layers - time - 1

chrome release 95.0.4638.54:
Creating 200 layers - time - 3
Moving 200 layers 100 px to left - time - 201
Clipping 200 layers - time - 0
Setting Opacity 10% - time - 181
Reverting z-index for 200 layers - time - 0
Moving with changing opacity and clip - time - 202
Inputing text into 200 layers - time - 5
Resizing 200 layers - time - 0

Whiteboard: [qf]

On linux Nightly is as fast or faster than Chrome.

jesup, could you perhaps file a new bug about the profiler improving perf. And maybe we could then close this one.

Flags: needinfo?(rjesup)
Whiteboard: [qf] → [qf:p5:responsiveness]

I have the same experience as Olli - on linux Nightly we're faster than Chrome on all of them.

We know that the profiler (on Windows) can cause the system timer to switch to hires mode (from 16ms mode), and that's almost certainly the reason.

Flags: needinfo?(rjesup)
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Performance Impact: --- → P3
Keywords: perf:responsiveness
Whiteboard: [qf:p5:responsiveness]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: