426854 - Testcase for bug 375225 noticeably slower than a week ago

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Kai de Leeuw]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040305 Minefield/3.0pre
Build Identifier: 

Not much, but I cannot repeatedly get 0.8 seconds on my computer anymore when I press the "DOM solution" button in attachment 260132 [details].

Now I get times like 0.9 seconds all the time. So approximately the testcase performs 10% slower than before.

I have killed off processes on my computer until it is really a bare bone set of processes running on my XP, but the numbers don't budge.

So my conclusion is that some check-in lately have made this testcase regress in terms of speed.

I will try to narrow down a regression range when I get the time. But if anyone knows of a related check-in, of course this would be nice.

Reproducible: Always

Steps to Reproduce:
1. Open attachment 260132 [details]
2. Press "DOM solution" button
Actual Results:  
Approximately 0.9 seconds on my machine.

Expected Results:  
Approximately 0.8 seconds on my machine. It was like this a few days ago. I promise!

Comment 1

[Johnny Stenback (:jst)]

Any chance you could download nightly or even hourly builds and see what build the number bumped in? That would greatly help in figuring out what might have caused this slowdown.

Comment 2

[Mike Kaply [:mkaply]]

Are you doing this in a profile that has NO extensions installed?

Comment 3

[François Gagné]

You may want to check with a clean profile (
http://kb.mozillazine.org/Profile_Manager ). Perhaps an newly added extension
changed the score you get?

See http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ for nightly builds
(check for 'trunk' in the directory name).

Comment 4

[Kai de Leeuw]

Yes, actually I have operator 0.9 installed, but it is disabled.
And that is the ONLY extension I have.

I tried also a clean profile.
Same numbers.

As I mentioned in the comment 0, I will narrow down a regression range as soon as I get the time.

Comment 5

[Kai de Leeuw]

I have downloaded some 15 nightlys or so, but it is extremely hard to narrow it down to two builds where in between the "slowdown" happened, but what I can see is that the build of March 23 is quicker than the build I had when I reported this bug (or the current one). 

I press the "DOM solution" button several times, and with the late builds I almost always get a number above 0.9s, but with a bit older I get a number above 0.8s but below 0.9s much more often. 

It is a very slight, but noticeable, change, and that is why I think I have such a hard time nailing it down to a specific build, maybe it is several contributing check-ins that slows the testcase down.

Comment 6

[Kai de Leeuw]

Now this gives 0.7 seconds on my machine, so this bug seems a bit unnecessary to keep open.

Marking as WFM as I don't know what has made the test case faster than when I filed this bug.