Closed Bug 277044 Opened 20 years ago Closed 19 years ago

DHTML performance regression with this particular testcase?

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: martijn.martijn, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(1 file)

2 oflline HTML docs as examples
75.55 KB, application/zip
Details 
The url dthml testcase is takes more cpu from my pc in current trunk builds,
than it was in older trunk builds.

This seem to be the regression dates, afaict:
cpu 35/45% - cpu 55/65% 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041114
Firefox/0.9.1+ 7:17am
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041115
Firefox/0.9.1+ 7:48am
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-11-14+07%3A00%3A00&maxdate=2004-11-15+08%3A00%3A00&cvsroot=%2Fcvsroot

cpu 55/65% - cpu 90/100% 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041126
Firefox/0.9.1+ 7:42am
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041127
Firefox/0.9.1+ 7:48am
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-11-26+07%3A00%3A00&maxdate=2004-11-27+08%3A00%3A00&cvsroot=%2Fcvsroot

I'm using a 800MHz Duron/128MB memory/nVidia Riva TNT2 M64 32MB. Screen setting
1024*768 16bit color depth.

I've made the following testcase with a simple animation:
http://martijn.heelveel.info/test/mozilla/slowdhtml/slow_relative2.html
Test results are inside the testcase.

The transparent image (which can be toggled to non-transparent) is inside a
position:relative (you can toggle this to static/absolute/fixed) <div>, wich is
inside a <table>. Also the little red block is inside this <div>.
Another test with a semi-automatic way of testing:
http://martijn.heelveel.info/test/mozilla/slowdhtml/slow_relative3.html
That first performance regression is almost certainly due to bug 261064 getting
fixed.  I'll profile it once my build finishes; we shouldn't need more time in
that testcase, I would think.

The second performance regression I'm not sure about... I can't quite reproduce
Martijn's results here -- I see extra CPU usage for position:fixed, but starting
with 2004-11-26-08, not with -27-07 (due to bug 209694?).  The fact that image
transparency affects what Martijn indicates a painting issue, not a layout
issue.  Maybe something weird and Windows-only from bug 228399?  That would
explain why I don't see it...
OK, so profiling shows us spending a lot of time in
nsAbsoluteContainingBlock::ReflowAbsoluteFrame.  If I remove the results div
from the DOM, I see a lot less in the way of CPU usage...  This is all on
http://martijn.heelveel.info/test/mozilla/slowdhtml/slow_relative2.html

Martijn, could you do another test?  If you set position:static on the results
div, do you see a performance problem for the rel pos case in a 2004-11-14-07
build on your testcase?
Flags: blocking1.8b?
I hope I understood you correctly. With the results div you mean the <div> where
you see the results I get, right? (with text "Test results (always using
Firefox....etc").
Setting this <div> to position:static doesn't influence the performance in a
negative way.


(In reply to comment #2)

> The second performance regression I'm not sure about... I can't quite reproduce
> Martijn's results here -- I see extra CPU usage for position:fixed, but starting
> with 2004-11-26-08, not with -27-07 (due to bug 209694?).  The fact that image
> transparency affects what Martijn indicates a painting issue, not a layout
> issue.  Maybe something weird and Windows-only from bug 228399?  That would
> explain why I don't see it...
Boris, I'm seeing the same here. See the results table in the testcase. The
2004-11-26 build seems slower for the case of position:fixed than the 2004-11-15
build. But because I had already two regression periods I didn't bother for that
one (which only seems to affect the position:fixed case). My mistake.
But now I've narrowed also that regression period down:
The 2004-11-25 10:19am build is still fast for the position:fixed testcase.
The 2004-11-26 7:42am build is slow for the position:fixed testcase (but not so
slow as the 2004-11-27 build)
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-11-25+10%3A00%3A00&maxdate=2004-11-26+08%3A00%3A00&cvsroot=%2Fcvsroot


Ok, I've used an old 2004-11-11 (debug) build.
Before I applied the fix for bug 261064, I get 8044ms for the position:relative
case.
After I applied the fix, I get 12568ms (and a high cpu use).
(In reply to comment #5)
> Boris, I'm seeing the same here. See the results table in the testcase. The
> 2004-11-26 build seems slower for the case of position:fixed than the 2004-11-15
> build. But because I had already two regression periods I didn't bother for
> that one (which only seems to affect the position:fixed case). My mistake.

Well.. The thing is, I'm not seeing the second regression you listed; just the
position:relative thing and the position:fixed thing.  That's why I suspect that
there is a Windows-only issue here.  Based on your regression range, the
position:fixed thing looks like bug 270804, by the way.

It may be worth filing 3 separate bugs on these regressions (assigned to
different people) and making this bug a tracker...

Also, if you can check my guesses on the other two patches, that would be most
helpful.
Depends on: 277760
Depends on: 277762
Depends on: 277766
Ok, I filed bug 277760, bug 277762 and bug 277766 and made them blocking this bug.
Could you assign those bugs, Boris? Afaik, ordinary mortals are not allowed to
assign bugs to someone (and I'm not sure whom to assign to, anyway).

By the way, I don't think bug 209694 cause a slow-down here (at least not in
windows).
I've tested this with:
Mozilla 2004-11-25-05 (just before the fix from bug 209694):
relative: transpare: 22242
absolute: transpare: 8021
fixed   : transpare: 8382
static  : transpare: 8032
relative: not_trans: 17966
absolute: not_trans: 8031
fixed   : not_trans: 8131
static  : not_trans: 8031
relative: div_block: 10935
absolute: div_block: 8031
fixed   : div_block: 8142
static  : div_block: 8032

Firefox 2004-11-25 10:19am (just after the fix from bug 209694):
relative: transpare: 22442
absolute: transpare: 8031
fixed   : transpare: 8372
static  : transpare: 8022
relative: not_trans: 18036
absolute: not_trans: 8032
fixed   : not_trans: 8132
static  : not_trans: 8031
relative: div_block: 11096
absolute: div_block: 8021
fixed   : div_block: 8122
static  : div_block: 8022

Results are in ms. As you can see, there is not much difference between those.
Martijn, thanks for testing all this!

I reassigned the bugs, but for future reference, you have the permissions to do
that yourself...
I soon have to revoke the beta document that is referenced here in the URL, so
I created 2 offline examples attached here. www.magnalox.net will go online
sometime next week, You'll then find there more examples.

I manually stripped off unrelated code and added ressources (that "save as" in
FF V1.0 didn't save, but displayed in the document properties - media dialog
btw.)

What I previously commented on bug 277044, especially comment #27 applies here
as well. Compare these 2 pages on IE and a recent FF build and watch the
choppyness of the crosshair cursor.

Try to cover the vertical green cursor (an empty DIV) with another window and
watch the CPU load, quite interesting.

All this was no problem on Gecko/20031007 Firebird/0.7, on what it was
developed that time... 

Cheers
too late for 1.8b1, transferring request to 1.8b2
Flags: blocking1.8b?
Flags: blocking1.8b2?
Flags: blocking1.8b-
Tested again with the trunc build from Feb 20 2005:
97% CPU usage, from 3% Gecko/20031007 Firebird/0.7

Most of the bugs mentioned are fixed, but it's not really a progress here, imho.
This bug was about a regression from the equivalent of Firefox 1.0.

If you see a regression in the 0.7 timeframe, that's not this bug.  File a
separate bug, localize the regression in time like Martijn did for this bug...
All url's I mentioned here can now be found here:
http://wargers.org/test/mozilla/slowdhtml/
Martijn, is this still an issue?
No. Me very happy :)
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Note: this was fixed by bug 284716.
Probably the blocking 1.8b2 should be removed (which I can't).
Flags: blocking1.8b2?
(In reply to comment #18)
> Probably the blocking 1.8b2 should be removed (which I can't).

Shouldn't it have been changed to - instead of removed? I don't know why
sometimes it is left as + after the bug has been fixed. Is there any consistency
or rhyme or reason to this marking?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: