Closed
Bug 140789
Opened 22 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)
Core
Layout
Tracking
()
RESOLVED
FIXED
| Performance Impact | low |
People
(Reporter: mozilla, Unassigned)
References
()
Details
(Keywords: perf, perf:responsiveness, testcase)
Attachments
(3 files)
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•22 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...)
|
||
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: petersen → rtvkuijk
|
|
||
Comment 2•22 years ago
|
||
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•22 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
|
||
Comment 4•22 years ago
|
||
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 :)
|
|
||
Comment 5•22 years ago
|
||
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•22 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•22 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.
|
|
||
Comment 8•22 years ago
|
||
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
|
|
||
Comment 9•22 years ago
|
||
Errata: On Mac, In Mozilla's results - Opacity changes taked 29106 miliseconds, not 2910.
|
||
Comment 10•22 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•22 years ago
|
|
||
Comment 11•22 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•22 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•22 years ago
|
||
I noticed when running these thest on IE my CPU (PIII/800MHz) also jumps to 100%... anybody else noticed this?
|
|
||
Comment 14•22 years ago
|
||
Bug 129115 has not been checked in yet, so comment #11 is incorrect.
|
|
Reporter | |
Comment 15•22 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•22 years ago
|
||
Gandalf: Perhaps you could make the same test with a background image in there. Markus mentioned bug 87808 in comment 11.
|
|
||
Comment 17•22 years ago
|
||
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•22 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!|
|
||
Comment 19•22 years ago
|
||
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•22 years ago
|
||
Also bug 75121 will be a major perf boost! besides bug 123668, bug 107746, bug 139986, bug 87808, bug 115247
|
||
Comment 21•22 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.|
|
||
Comment 22•22 years ago
|
||
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.
|
|
||
Comment 23•22 years ago
|
||
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•22 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•22 years ago
|
||
Probably it's related to the checkin of bug 124685.
|
|
||
Comment 26•22 years ago
|
||
Is it setting "10%" or "0.1"? The former is much slower and does not do the same thing as "0.1"....
|
|
||
Comment 27•22 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)|
|
||
Comment 28•22 years ago
|
||
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•22 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•22 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.|
|
||
Comment 31•22 years ago
|
||
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.
|
|
||
Comment 32•22 years ago
|
||
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•22 years ago
|
||
gandalf, could you provide a file with comment #31 incorporated? e.g. as dynl-c31.html
|
|
||
Comment 34•22 years ago
|
||
http://alladyn.art.pl/gandalf/MozillaTests/dynl-c31.html - ready.
|
|
||
Comment 35•22 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.|
|
||
Comment 36•22 years ago
|
||
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.
|
|
||
Comment 37•22 years ago
|
||
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•22 years ago
|
||
Regression reported in bug 169748 - seems overal moving is slowed down considerably - most probably due to bug 164931.
|
||
Comment 39•22 years ago
|
||
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.
|
|
||
Comment 40•22 years ago
|
||
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.
|
|
||
Comment 41•22 years ago
|
||
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•22 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•22 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•22 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•22 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•22 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.|
|
||
Comment 48•22 years ago
|
||
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
|
|
||
Comment 49•22 years ago
|
||
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•22 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 ;-)
|
|
||
Comment 51•22 years ago
|
||
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.
|
|
||
Comment 52•22 years ago
|
||
Boris. Thank You for what You're doing. Shouldn't we create self bug for Opacity performance? I see this as separate bug. Right?
|
|
||
Comment 53•22 years ago
|
||
Sure, feel free to file one if there isn't one already...
|
|
||
Comment 54•22 years ago
|
||
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
|
|
||
Comment 55•22 years ago
|
||
Great... any other plans to regress DHTML performance??? Bz, do you have any idea, why there is so big difference?
|
|
||
Comment 56•22 years ago
|
||
On which test?
|
||
Comment 57•22 years ago
|
||
I believe on the test you posted. Values with patch are worse than witout...
|
|
||
Comment 58•22 years ago
|
||
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•22 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.|
|
||
Comment 61•22 years ago
|
||
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•22 years ago
|
|
|
||
Comment 62•22 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.
|
|
||
Comment 63•22 years ago
|
||
Robert. Tests on 1.1 and 1.2.1 were made really on same machine??? Big, big regression...
|
|
Reporter | |
Comment 64•22 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•22 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•22 years ago
|
||
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•22 years ago
|
||
The time-frame of the regression seems to correlate with the one seen in bug 186133
|
|
||
Comment 68•22 years ago
|
||
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.
|
|
||
Comment 70•22 years ago
|
||
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•22 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...|
|
||
Comment 72•21 years ago
|
||
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.
|
|
||
Comment 73•21 years ago
|
||
I'll do this tommorow for windows and MacOSX. Someone could do it for Linux?
|
|
||
Comment 74•21 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%
|
|
||
Comment 75•21 years ago
|
||
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?|
|
||
Comment 76•21 years ago
|
||
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....
|
|
||
Comment 77•21 years ago
|
||
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....|
|
||
Comment 78•21 years ago
|
||
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?|
|
||
Comment 79•21 years ago
|
||
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.
|
|
||
Comment 80•21 years ago
|
||
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.
|
|
||
Comment 81•21 years ago
|
||
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•21 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•21 years ago
|
||
re Comment #82, first line: it's been a bit less than 1 month. damn copy & paste thing.
|
|
||
Comment 84•21 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. ;)
|
|
||
Comment 85•21 years ago
|
||
Um. Ok.... Now I'm a little confused, but..... ;)
|
|
||
Comment 86•21 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•21 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•21 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.
|
|
||
Comment 89•21 years ago
|
||
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•21 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]
|
|
||
Comment 91•21 years ago
|
||
Probably not with 1.5a. With 1.6a, maybe. It's hard to get close to numbers produced by incorrectly working code... ;)
|
|
||
Updated•21 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
|
|
||
Comment 92•21 years ago
|
||
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?
|
|
||
Comment 93•21 years ago
|
||
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•21 years ago
|
||
shouldn't 'creating 200...' also be 6%? nice numbers indeed
|
|
||
Comment 95•21 years ago
|
||
btw, more stuff is happening in bug 188803; once the second patch lands people may want to test again...
|
|
||
Comment 96•21 years ago
|
||
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.
|
|
||
Comment 97•21 years ago
|
||
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•21 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•21 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?
|
|
||
Comment 100•21 years ago
|
||
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•21 years ago
|
||
Oh, fine. Filed bug 210525 for another quite interesting test-suite to keep track of.
|
|
||
Comment 102•21 years ago
|
||
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.
|
||
Comment 103•21 years ago
|
||
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
|
|
||
Comment 104•21 years ago
|
||
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?
|
|
||
Comment 105•21 years ago
|
||
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
|
|
||
Comment 106•21 years ago
|
||
No problem, DIVs with images - gif(animated?),png,jpg,mixed?
|
|
||
Comment 107•21 years ago
|
||
I doubt that it matters much, really... If we decide it does, the answer would have to be "all of the above" ;)
|
|
||
Comment 108•20 years ago
|
||
What are the numbers with a recent build?
|
|
||
Comment 109•20 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
|
|
||
Comment 110•20 years ago
|
||
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
|
|
||
Comment 111•20 years ago
|
||
Can you test a trunk build, please? Testing branch for DHTML performance is pretty pointless by now.
|
|
||
Comment 112•20 years ago
|
||
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
|
|
||
Comment 113•20 years ago
|
||
in trunk test the better part was that the animation was animation rather than a 2 frame slide show - with first and last frame.
|
|
||
Comment 114•20 years ago
|
||
OK. Sounds like we're not doing too badly then (the non-animation testcase times are way down from the branch numbers).
|
|
||
Comment 115•20 years ago
|
||
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 .
|
|
||
Comment 116•20 years ago
|
||
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.
|
|
||
Comment 118•20 years ago
|
||
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 :)
|
|
||
Comment 119•20 years ago
|
||
Ah, no. If we already have bugs on opacity, no point to filing another one. ;)
|
|
||
Comment 120•19 years ago
|
||
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 :(
|
|
||
Comment 121•19 years ago
|
||
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...
|
|
||
Comment 122•19 years ago
|
||
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?
|
|
||
Comment 123•19 years ago
|
||
> 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.
|
|
||
Comment 125•19 years ago
|
||
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.
|
|
||
Comment 126•19 years ago
|
||
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.|
|
||
Comment 127•19 years ago
|
||
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.|
|
||
Comment 128•16 years ago
|
||
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|
|
||
Updated•16 years ago
|
|
|
||
Comment 129•16 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 :)|
|
||
Comment 130•16 years ago
|
||
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.
|
|
||
Comment 132•16 years ago
|
||
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.
|
|
||
Comment 133•16 years ago
|
||
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.|
|
||
Comment 134•16 years ago
|
||
oh, forgot to say, the above results are for 400 divs instead of 200. It's just more visible then. Attaching
|
||
Updated•15 years ago
|
QA Contact: mozilla → layout
|
|
Reporter | |
Updated•13 years ago
|
Assignee: mozilla → nobody
|
|
||
Comment 135•12 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
|
||
Comment 136•3 years ago
|
||
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]
|
||
Comment 137•3 years ago
|
||
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]
|
|
||
Comment 138•3 years ago
|
||
I have the same experience as Olli - on linux Nightly we're faster than Chrome on all of them.
|
|
||
Comment 139•3 years ago
|
||
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)
|
|
||
Updated•3 years ago
|
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
|
||
Updated•2 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•