This one is for keeping track on the performance of the simple layer animation/movmenet tests at http://www.world-direct.com/mozilla/dhtml/funo/dhtmltest1to10ms.htm [for intervals of 1ms to 10ms] and http://www.world-direct.com/mozilla/dhtml/funo/dhtmltest_10to20ms.htm [for intervals of 10ms to 20ms] My system, PIII 1.1ghz,512ram,32mb geforce2go trunk build 2003062408 1-10ms : 4239.1ms 10-20ms : 5303.09ms MSIE 6 SP1 1-10ms : 2539.7ms 10-20ms : 4806.00ms Opera 7.11 1-10ms : 2522.6ms 10-20ms : 4814.27ms Mozilla1.3 1-10ms : 4235.1ms 10-20ms : 4806.00ms Mozilla1.2.1 1-10ms : 4216.1ms 10-20ms : 5307.63ms Depending on the selected ms timeout the animation is most of the time quite choppy. This is very similar to the findings mentioned in bug 129496 (running smooth, then choppy, smooth again, choppy again, etc.) - maybe this might also get better once bug 123668 is in. MSIE and Opera are running smooth througout all timeout values.

Or maybe we can tweak our performance in the 1-10ms range (which is most used on the web) by optimizing the PL_Event notification resp. bug 169247 ?

hard to guess if that is correct. you might want to try counting the number of PLEvent objects allocated during a typical test run.

yeah, I think we need some profiling done here before we can really see what's going on. Also, I sped up getElementById() recently, it might be worth seeing if that affected this.

just for the record here's some basic numbers on the mac side. Moz builds are what i had on hand. someone wanna take a stab at the best set of builds to test? g4/400mhz/1gbram best of 2 or 3 runs moz1.0.2 moz1.4 moz03070108 safari1.0 msie5.2.3 test 1 2874.6* 3277.3 3240.9 10693.7 2260.0 test 2 5112.7 4531.5 4510.9 10833.2 4253.0 * first 2 passes seem to go without painting

Kmcclusk once made timeouts to be a minimum of 10ms if I remember correctly - but MSIE is having also this behaviour afaik - but is doing things a lot faster. Hopefully a profile will bring up some light here.

To count PLEVent objects: You can do this: a) define PL_POST_TIMINGS in xpcom/threads/Makefile.in b) on line 707 of plevent.c, change the printf to report s_eventCount. c) rebuild xpcom/threads and xpcom/build. This will print you the number of total PLEvents that have been properly destroyed.

Made this test on a 2,53Ghz P4 with Win2K and a Radeon 9500 Pro on current CVS trunk build (with that Patch for Bug 83536, perhaps that's related, i heard so from matic :) test1to10ms: Average time: 2689.1ms test10to20ms: Average time: 3917.6363636363635ms. More detailed test : test1to20ms 1ms timeout : 2688ms. 2ms timeout : 2687ms. 3ms timeout : 2688ms. 4ms timeout : 2687ms. 5ms timeout : 2688ms. 6ms timeout : 2687ms. 7ms timeout : 2703ms. 8ms timeout : 2688ms. 9ms timeout : 2687ms. 10ms timeout : 2688ms. Average time: 2689.1ms test10to20ms: 10ms timeout : 2688ms. 11ms timeout : 2922ms. 12ms timeout : 3187ms. 13ms timeout : 3422ms. 14ms timeout : 3656ms. 15ms timeout : 3906ms. 16ms timeout : 4172ms. 17ms timeout : 4407ms. 18ms timeout : 4656ms. 19ms timeout : 4922ms. 20ms timeout : 5172ms. Average time: 3919.090909090909ms. I noticed on both tests that when i press the start button more and more the timeout decreases more and more and the animation gets faster. btw: Also when a page with many tables/complicated tables(?) loads in another tab, the average time incresaes about 1 second, but that's another issue (example page would be http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey).

>> I noticed on both tests that when i press the start button more and more the timeout decreases more and more and the animation gets faster. << Thats a bug in the testcase. It's resolved in http://www.world-direct.com/mozilla/dhtml/funo/dhtmltest1to10ms_modified.htm but the benchmark output for the TimeOut line is corrupted.

I've attached a patch in bug 213813 that might help with some of these DHTML issues. I don't expect tremendous gains, but it might be a small step in improving performance. I'm going to try and get some numbers, but I wanted to get this out to others that might have more time than I have current. The patch is at http://bugzilla.mozilla.org/attachment.cgi?id=128862&action=edit

test page is offline so please close this bug