Closed Bug 328374 Opened 14 years ago Closed 12 years ago
DHTML performance regression because of cairo
The url is from bug 277762. I'm using a Duron 800MHz, NVidia GeForce2 MX 100/200 32MB, screen setting 1024*768 32bit color depth. To begin the testcase, click on the button "Automatic test for all()". These are my results: Results build: 02-22 (non-cairo) 02-23 (cairo) relative: transpare: 8032 20499 absolute: transpare: 8032 14210 fixed : transpare: 8032 14140 static : transpare: 8012 8032 relative: not_trans: 8032 20169 absolute: not_trans: 8032 14070 fixed : not_trans: 8032 14031 static : not_trans: 8022 8031 relative: div_block: 8032 10795 absolute: div_block: 8032 8031 fixed : div_block: 8032 8031 static : div_block: 8012 8031 As you can see Cairo builds are quite slower than non-Cairo builds. Static/absolute/fixed/relative means the containing <div> is positioned in that way. transpare means the image in the background is transparent not_trans means the image in the background is not transparent div_block means the background is a green div
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060407 Firefox/3.0a1 Have you got any recent numbers? A quick test for me shows that only relative-transpare and relative-not-transpare are slower in cairo-gtk2 vs. gtk2. However, I don't know if that's a difference because your results are from Windows, or because they're a month and a half old :-)
I've tested bug 328367 recently, and that still gave the bad performance, so I'm quite sure this also is not solved for me. If you're seeing performance issues with this testcase under Linux, please file a new bug for that and mention the bug number here.
Vlad, pav, any idea what might be up here?
Not offhand; on my laptop, forced down to 787MHz, I get 8031 for all the tests with a recent trunk windows nightly. What is the measurement? Total number of milliseconds that it takes to move the block down, and 8s is the expected result due to timing?
(In reply to comment #4) > Not offhand; on my laptop, forced down to 787MHz, I get 8031 for all the tests > with a recent trunk windows nightly. What is the measurement? Total number of > milliseconds that it takes to move the block down, and 8s is the expected > result due to timing? Yes, it is indeed in milliseconds. Actually, I'm not sure what the expected result would be, but I would expect a result comparable with a non-Cairo build. Results I get with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060427 Minefield/3.0a1 Results: relative: transpare: 19988 absolute: transpare: 14731 fixed : transpare: 14361 static : transpare: 8022 relative: not_trans: 18597 absolute: not_trans: 12348 fixed : not_trans: 12377 static : not_trans: 8031 relative: div_block: 11336 absolute: div_block: 8032 fixed : div_block: 8032 static : div_block: 8032
Note that in the past we've discovered these things to be strongly video-hardware-related in many cases (eg DIB vs DDB perf on different cards, etc). See bug 277762. Not sure that's necessarily the case here, of course. The time it takes to run the testcase on an infinitely fast machine is 400*20 = 8000 ms (400 steps, 20ms timeout). You could try doing a 10ms timeout locally instead of 20ms... That might show the bug better.
So this seems to be fixed with the patch from bug 343655! I've compared between the 2006-08-09 and 2006-08-10 build: Results in ms: 2006-08-09 2006-08-10 relative: transpare: 14651 8022 absolute: transpare: 9804 8022 fixed : transpare: 9844 8022 static : transpare: 8021 8022 relative: not_trans: 13229 8022 absolute: not_trans: 8563 8022 fixed : not_trans: 8482 8022 static : not_trans: 8021 8022 relative: div_block: 8021 8022 absolute: div_block: 8021 8022 fixed : div_block: 8022 8022 static : div_block: 8022 8021 So with the 2006-08-10 build, I get the results like I used to. So this bug is basically fixed, but the testcase suffers from bug 348191 currently (transparent gifs that are black). I want to retest when that bug gets fixed.
Martijn, can you please retest and give a short feedback.
Sorry for the delay, I actually tested this already some time ago. It is mostly fixed on my 800MHz computer, however when I increase the amount of elements that are moved, then I still can see a small slow-down in cairo builds. But I need to test this some more (and just test between cairo and non-cairo builds. I'll try to do that in the next few days. Results: ff22.214.171.124 2006-08-13 relative: transpare: 9774 16393 absolute: transpare: 8783 14341 fixed : transpare: 9353 14460 static : transpare: 8482 10244 relative: not_trans: 9564 13089 absolute: not_trans: 8482 10115 fixed : not_trans: 9063 10515 static : not_trans: 8442 10054 relative: div_block: 9484 12978 absolute: div_block: 8533 10204 fixed : div_block: 8883 10575 static : div_block: 8463 9945
13 years ago
Assignee: nobody → vladimir
Flags: blocking1.9? → blocking1.9-
With 10ms timeout, as suggested in comment #6 Results: SM1.1.7 FF3.0b5pre relative: transpare: 9937 6365 absolute: transpare: 7672 6324 fixed : transpare: 7453 6275 static : transpare: 7188 6268 relative: not_trans: 9219 6266 absolute: not_trans: 7640 6262 fixed : not_trans: 7672 6266 static : not_trans: 7312 6266 relative: div_block: 7750 6266 absolute: div_block: 7688 6571 fixed : div_block: 7640 6266 static : div_block: 7140 6657 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20071128 SeaMonkey/1.1.7 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031605 Minefield/3.0b5pre Cairo is now faster
Confirm on Linux: Results: Fx1.5 Fx3.0b5pre relative: transpare: 5977 5028 absolute: transpare: 5935 5572 fixed : transpare: 5915 5000 static : transpare: 5939 4980 relative: not_trans: 5927 4977 absolute: not_trans: 5943 5024 fixed : not_trans: 5934 5027 static : not_trans: 5923 5007 relative: div_block: 5954 5038 absolute: div_block: 5921 5002 fixed : div_block: 5943 4997 static : div_block: 5918 5002 closing as WFM, reopen if MacOS is still slower
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Ok, on branch, with the unminimized testcase, I get: Results: relative: transpare: 9171 absolute: transpare: 9297 fixed : transpare: 9625 static : transpare: 9312 relative: not_trans: 9094 absolute: not_trans: 9250 fixed : not_trans: 9407 static : not_trans: 9078 relative: div_block: 9593 absolute: div_block: 9219 fixed : div_block: 9204 static : div_block: 8891 On current trunk, I get: Results: relative: transpare: 8123 absolute: transpare: 8088 fixed : transpare: 8356 static : transpare: 8035 relative: not_trans: 8271 absolute: not_trans: 8027 fixed : not_trans: 8041 static : not_trans: 8251 relative: div_block: 8052 absolute: div_block: 8242 fixed : div_block: 8603 static : div_block: 8354 So this indeed seems fixed. But I don't think trunk is really faster, I suspect timers are working differently on trunk (better).
Status: RESOLVED → VERIFIED
On trunk, timers work better, and JS itself is faster. The drawing issue this was initially filed on may or may not have been fixed.
You need to log in before you can comment on or make changes to this bug.