Closed Bug 169748 Opened 22 years ago Closed 22 years ago

DHTML performance regression

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: markushuebner, Assigned: dcone)

References

(
URL
)

Details

(Keywords: perf, regression, testcase)

Attachments

(1 file)

Results of the testcase over the various builds
5.36 KB, text/plain
Details 
Doing a recent testing with nightly 2002091208 showed that we do
considerably slower on the testcase.

I already tun the testcase sometime ago:

trunk 2002091208 | trunk 2002052008 | msie6 | opera6.0 | ns4.78
---------------------------------------------------------------
8492             | 4957             | 1502  | 1502     | 3715

Test-workstation has 1.1ghz, 512ram, 32mb geforce2 go

Maybe bug 157144 might have an impact on the slowdown?
Keywords: perf, regression, testcase
Blocks: 21762
On my Celeron 1,06GHz, Intel 830M, WinXP, trunk build 2002091908 it isn't that
slow, but don't know the exact number as it doesn't give me the dialog. But then
again this build includes fix for bug 157144.
More tests: 

Mozilla 1.0 | Mozilla 1.1a | Mozilla 1.1b
----------------------------------------------------
7080        | 7070         | 2884

Here are more tests

On an Athlon 1333 512 DDR Nvidia TNT2 with Linux

2002091804 |               |
------------------------------------------
2575       |               | 

On a Imac PowerPC G3 233 192 RAM

Mozilla 1.0 |               |
----------------------------
54830       |               |

And mozilla on Mac is really slow  :)
Attinasi is gone - reassigning to dbaron
Assignee: attinasi → dbaron
on linux, the testcase runs about the same with 1.0 through current trunk 
7500 +/- 500 ms.  tested on 450 MHz P-II, RIVA TNT (16MB)
Here we go again. On my work machine (Athlon XP 2200+, 512MB, G550) it gets much
faster when I change color depth. No matter if I change it up or down. I think
this is the same as http://bugzilla.mozilla.org/show_bug.cgi?id=117436#c30
(which was shot down because of a flaw in the test case). In this case even
Ctrl-Reload is fast. After restarting Mozilla it is slow again.
Athlon 750, Win2k SP3

Mozilla 1.2 trunk 20020909 - 6800 ms
IE6 SP1 - 1502 ms
--

After changing Color Deph (from 32 bit to 16 bit) - 3352 ms
After switching Color Deph back - 1786 ms

I'm very afraid to change it one more...
Please report the color switch problems in bug 157072
ouch - at the testcase at
http://www.world-direct.com/mozilla/dhtml/timeouttest.htm
got 4 times worse than it used to be!! - see for milestone results overview.

My check in for bug 164931 probably affected this. see the follow comments
http://bugzilla.mozilla.org/show_bug.cgi?id=164931#c12
http://bugzilla.mozilla.org/show_bug.cgi?id=164931#c24

The maximum frame is now 100fps now that we use timers instead of posted WM_APP
events for plevent notification.
Well, if you look at the testcase at
http://www.world-direct.com/mozilla/dhtml/timeouttest.htm
the current build is far away from 100 fps - more like 1 fps.

using 2002092008 trunk build on WinXP 750Mhz machine.

Actual time :: Time between setTimeout and function:
100 :: 90
190 :: 90
290 :: 100
390 :: 100
530 :: 140
681 :: 151
821 :: 140
941 :: 120
1051 :: 110
1161 :: 110
1261 :: 100
1361 :: 100
1452 :: 91
1562 :: 110
...
wow - something strang's going on here:
trunk build 2002091908 on win-xp pro,1.1ghz,512ram (see complete testresults 
in attachment).

1021 :: 1021
2043 :: 1022
3064 :: 1011
4095 :: 1021
5117 :: 1022
6138 :: 1021
7160 :: 1022
8181 :: 1021
9203 :: 1012
10234 :: 1021
11256 :: 1022
12277 :: 1021
...

so that's about 10 times slower!

Tested now all available nightlies on ftp (puhh!) and 0.9.7 till 1.2a --> it 
seems that my last GeForece2 Go driver update makes this now that slow, as the 
slowdown happens on all recent builds now. Also affecting the testcase at
http://www.world-direct.com/mozilla/dhtml/75121/anim-test.htm
Just 0.9.8 behaved as it was before the video driver update.
Did we change something considerably in view of scaling/painting after 0.9.8 ?

What is still as fast as msie is the testcase at
http://www.world-direct.com/mozilla/tt/timeouttest_resized.htm
(the ball.gif is already resized to mozilla doesn't have to do it) which 
delivers 110 as average.

I will do further investigations with all builds on several other workstations.

firstly, my system is: Athlon 1.2 GHz, 3dfx Voodoo 3 2000, Win98 SE
ok, testcase results:
http://www.world-direct.com/mozilla/dhtml/75121/anim-test.htm
mozilla 2002092008: 5650
netscape 7 RTM: 2580

http://www.world-direct.com/mozilla/dhtml/timeouttest.htm
mozilla 2002092008: between 170 and 220
netscape 7 RTM: between 50 and 110
Biesi, does changing color depth make any difference (a la comment #6) for you?
ere: it does. anim-test (haven't tried the other one) now takes twice as long.
(I switched 16bit->32bit)
Well, that's something else then. For me it works much better on my work machine
if I change the color depth (from 16bit to 32 or vice versa). On my home
machine, there is no difference. There are too many moving things here..
DHTML performance regression also noticed in bug 140789.
For comparison:
Animtest:
Konqueror 3.0.3,Linux 2.4,Nvidia GF, K6-3 500MHz, 192 MB sdram: 2050ms
Mozilla 1.0, 19.10.02, Linux 2.4,Nvidia GF, K6-3 500MHz, 192 MB sdram: 4000ms
(looks a bit strange)
Trunk 20020921

761 :: 741
1492 :: 721
2323 :: 821
3274 :: 941
4206 :: 922
5057 :: 841
5838 :: 771
6839 :: 991
7981 :: 1132
8672 :: 671
9333 :: 651
9994 :: 651
10655 :: 651
11496 :: 831
12417 :: 891
13158 :: 721
13960 :: 791
14811 :: 841
15542 :: 721
16724 :: 1172
17655 :: 921
18516 :: 851
19247 :: 721
20259 :: 1002
...
Forgot to add system spec: Win2k Athlon 750 .

And it is regression.
I'm seeing around 2000ms for the testcase on both 1.1 and a current cvs build on
Linux. As bug 164931 is a win32 only patch, it really seems suspect to have
caused this for win32 people.
->kmcclusk, based on Markus's email telling me that the regression is from bug
164931.

Is this more of a problem on certain Windows OSes than others?
Assignee: dbaron → kmcclusk
Hmmm. This bug was originally reported using a 2002091208 build which pre-dates
the 9/18 checkin for bug 164931?

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? 

From Markus's comment: http://bugzilla.mozilla.org/show_bug.cgi?id=169748#c15 it
sounds like the performance regression is sensitive to the graphics card and
driver, which indicates it is probably related to rendering of images. I don't
think the performance regression is caused by or made worse by the checkin for
bug 164931.
Since according to the comment 15
http://www.world-direct.com/mozilla/tt/timeouttest_resized.htm does not have the
performance regression and Moz 098 works fine for images that need to scaled. I
would guess the performance regression was introduced back when imagelib was
changed to scale images when rendered instead of pre-scaling them?.  

saari, pav, dcone: Does this sound right? 
Just did testing on two worksations having ATI graphics cards on winnt.
There is no difference between 9/16 and 9/20 builds.

But I made some further investigation and got a nice finding - could achieve a 
performance boost by factor 10(!) on my GeForce2 Go graphics card.
Just see bug 170272.
QA Contact: petersen → amar
-> Don.
Assignee: kmcclusk → dcone
Priority: -- → P2
Color depth.. info for everyone.
We create DDB's for a given screen.  This means that image is optimized for the
card at the depth that the image is created for,  and if you switch depths..
after the creation of this image.. it could slow the blit time down as much as
100 times.. depending on the graphics card.  This is just a -Beware- note.
Then why we're not reciving any problems with slowing down after deph change?
In the same time we're reciving many info about quite nice improvements. Is that
logic?
Bulk moving P1-P5 un-milestoned bugs to future.
Target Milestone: --- → Future
Marking fixed - fixing bug 170272 did a nice job :)
Further investigation about the color switch phenomenon will go on in bug 
157072.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
No longer blocks: 21762
Blocks: 21762
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: