highlighter is slower when inspecting elements

RESOLVED DUPLICATE of bug 770818

Status

P1
normal
RESOLVED DUPLICATE of bug 770818
7 years ago
6 months ago

People

(Reporter: sys.sgx, Assigned: paul)

Tracking

({perf, qawanted, regression})

14 Branch
perf, qawanted, regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: performance)

Attachments

(3 attachments)

(Reporter)

Description

7 years ago
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20120311 Firefox/13.0a1
Build ID: 20120311031030

Steps to reproduce:

Machine: windows x86.
Between Firefox versions 11 and 13, there's a difference in the speed one is able to move around in a webpage.

If you click the inspect tool in free mode in Firefox 11 it's much faster for the browser to highlight the hovered element in the screen than in 13. Maybe it's because the new is a trunk built, but it might be good looking at it.
(Reporter)

Updated

7 years ago
Component: Untriaged → Developer Tools: Inspector
(Assignee)

Comment 1

7 years ago
Do you have the same problem with Firefox 12? I suspect bug 566092.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Style Inspector - Speed of tool → highlighter is slower
Whiteboard: performance
(Reporter)

Comment 2

7 years ago
I think the bug you mentioned is not related to this one, bug i gotta tell you that the inspector in 12a2 is supremely fast! :-)

yep, there are some ms difference between 12a2 and 13a1 and it's easy to see. I'd prefer to have the 12a2 version.
thanks
(Assignee)

Comment 3

7 years ago
(In reply to sys.sgx from comment #2)
> I think the bug you mentioned is not related to this one,

why?

Can you bisect and see when it regressed?
(you can use this tool: http://harthur.github.com/mozregression/)
(Assignee)

Updated

7 years ago
Priority: -- → P1
(Assignee)

Comment 4

7 years ago
Let me know if you need any help to find the regression range.
(Reporter)

Comment 5

7 years ago
It's not related but because i'm talking about speed, pure speed of how quickly the inspector can highlight elements while moving around the mouse on the screen.
Btw, https://bugzilla.mozilla.org/show_bug.cgi?id=453650 is still open.

yep, I can run the mozregression, though I think it's something you can very easily test yourself since you know how it works. It's the difference between firefox 12a2 today's build and firefox 13.0a1 (2012-03-12).

So, how will this be asked to the command line? (it's two different channels, and I think the updates of the builds of each channel are daily both, so there are two same dates to check)

Let me know any news on this.
(Assignee)

Comment 6

7 years ago
(In reply to sys.sgx from comment #5)
> It's not related but because i'm talking about speed, pure speed of how
> quickly the inspector can highlight elements while moving around the mouse
> on the screen.

So what? I understand that very well, and I think it's because of bug 566092.
The way we fixed this bug slows down the highlighter.

> Btw, https://bugzilla.mozilla.org/show_bug.cgi?id=453650 is still open.

And?

> yep, I can run the mozregression, though I think it's something you can very
> easily test yourself since you know how it works. It's the difference
> between firefox 12a2 today's build and firefox 13.0a1 (2012-03-12).

This is not helping.

> So, how will this be asked to the command line? (it's two different
> channels, and I think the updates of the builds of each channel are daily
> both, so there are two same dates to check)

No. Just start with the wrong one (2012-03-12).
(Reporter)

Comment 7

7 years ago
So 566092 is probably causing this. I'll check when there's time soon and I'll let you know.
(Reporter)

Comment 8

7 years ago
paul, just checked the mozregression page. the current machine i'm working on is configured for a set of rules, so this means I'll have to find another pc to check it. will let you know if there any news.
(Assignee)

Comment 9

7 years ago
(In reply to sys.sgx from comment #8)
> paul, just checked the mozregression page. the current machine i'm working
> on is configured for a set of rules, so this means I'll have to find another
> pc to check it. will let you know if there any news.

Understood, thank you!
(Assignee)

Comment 10

7 years ago
Sys, is the Sidebar open when you have this performance problem?
(Reporter)

Comment 11

7 years ago
hey, just checked it with Firefox 14a1, which is even worse than firefox 13.
The sidebar does add about 50ms more time when moving around the page, but even with the sidebar closed there's many ms difference between this and firefox 12.
(Reporter)

Updated

7 years ago
OS: Windows Vista → All
Hardware: x86 → All
Version: 13 Branch → 14 Branch
(Assignee)

Updated

7 years ago
Assignee: nobody → paul
Status: NEW → ASSIGNED
(Assignee)

Comment 12

7 years ago
Sys, an experimental build will be available here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/prouget@mozilla.com-12fde1bbeb07 (builds will be available in a couple of hours).

Please let me know if it fixes the performance problem (but keep the sidebar closed).

Thank you.
(Reporter)

Comment 13

7 years ago
ok. plz try to keep the builds in zip files, not very keen on new installations. will let you know.
(Reporter)

Comment 14

7 years ago
I checked the experimental build, and it's the same speed as with the 14a1. ok, here's my view: the fastest ever build is this one, http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/12.0b1-candidates/build1/win32/en-US/ . If you check build2 of firefox 12 beta it's not as fast as build1 (small difference though). So, you might want to check what did change between build1 and build2 of version 12.
(Reporter)

Updated

7 years ago
Summary: highlighter is slower → highlighter is slower when inspecting elements
(Assignee)

Comment 15

7 years ago
What do you call build 2?

It would really really help me if you could use mozregression: http://harthur.github.com/mozregression/
(Reporter)

Comment 17

7 years ago
as I mentioned in my previous message, installing mozillabuild will only be possible in like a week. i'll let you know.
QA Contact: untriaged → developer.tools.inspector
can anyone to find a proper regression range for this?
Keywords: qawanted
(Assignee)

Comment 19

7 years ago
Sys, any update on this?
(Reporter)

Comment 20

7 years ago
hi paul. there are things to do on this machine, so installing the entire mozilla build will be possible in the future. But zip files are ok, I've just checked it between v14 trunk and v12b3, and it's still faster in 12b3. You might want some more QA for this.
(Assignee)

Comment 21

7 years ago
Hi Sys. You don't need to install anything. mozregression only use zip files.

There are hundreds of changesets between v14 and v12b3, we really need a regression range. And the performance problem is hard to reproduce here, so I can't do it for you :(

It would really really help if you could try again to use mozregression. And if you can't use it, can you please explain exactly what kind of problem you are running into?
(Reporter)

Comment 22

7 years ago
How do you set first good date of 12b3? it seems mozregression only deals with nightlies. well, how do you know which nightly is 12b3?
(Assignee)

Comment 23

7 years ago
It's ok, you can start with an early nightly. A wide initial range is not a problem:

mozregression --bad=2012-03-30 --good=2012-01-01
(Reporter)

Comment 24

7 years ago
here's your list, the way the UI seems to be:

1. http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-02-27&enddate=2
012-02-28: small change in speed

2. http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d1b2fd680235&tochan
ge=7ce4d9b55863: major change in speed

The best version was from 2012-02-26

Let us know any news on this.
(Reporter)

Comment 25

7 years ago
note: the previous post was saying that there's a small speed change between 2012-02-26 - 2012-02-27 and a big speed change between 2012-02-27 - 2012-02-28.

The best version was from 2012-02-26, very good UI.
(Assignee)

Comment 26

7 years ago
Thank you very much Sys! This is very helpfull.

I will prepare one or to builds that you'll be able to test.
aha!

Thanks for the data, sys. Exactly what was needed.
(Assignee)

Comment 29

7 years ago
If, indeed, it's a problem with the `DOMUtils.hasPseudoClassLock` call, is it slow because 1) XPConnect, or 2) because of what `hasPseudoClassLock` does?

If 1), we can't do much. We will need to update the infobar less often. But this is totally doable.

If 2), can we fix `hasPseudoClassLock`?
Do you still see this with the html and style panels closed?
(Assignee)

Comment 32

7 years ago
Here is a build without the DOMUtils.hasPseudoClassLock calls (and the related DOM modifications).

Sys, can you try this build and tell us if you still have a performance problem: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/prouget@mozilla.com-fb699161110e/
(Reporter)

Comment 33

7 years ago
paul, i checked this directory http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/prouget@mozilla.com-fb699161110e/try-win32/, and this build has even greater speed difference than all the other builds. This is with all panels closed, and with only cpu acceleration.
(Assignee)

Comment 34

7 years ago
(In reply to sys.sgx from comment #33)
> paul, i checked this directory
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/prouget@mozilla.
> com-fb699161110e/try-win32/, and this build has even greater speed
> difference than all the other builds. This is with all panels closed, and
> with only cpu acceleration.

You mean slower or faster?
(Reporter)

Comment 35

7 years ago
well, it's slower...
A good way to see speed is to open the bugzilla pages (ie the DevTools) and try to hover fast in an "8" like pattern on the screen. The build you posted shows like 4-5 tooltip items of 12 elements total hovered, but the faster version shows all tooltips of all elements instantly. It's something you can easily see.
(Assignee)

Comment 36

7 years ago
I can, indeed, reproduce. Woot!
I will work on that next week.
(Assignee)

Comment 37

7 years ago
Created attachment 616106 [details]
Firefox Nightly (April) - mozilla.org build
(Assignee)

Comment 38

7 years ago
Created attachment 616107 [details]
Firefox Nightly (April) - paul's build
(Assignee)

Comment 39

7 years ago
Created attachment 616108 [details]
Firefox, before February 27th - mozilla.org build
(Assignee)

Comment 40

7 years ago
First, I want to confirm Sys' regression window:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d1b2fd680235&tochange=7ce4d9b55863

Apparently, this regression is related to a change in how we build Firefox.
When I build central myself, I don't have the performance regression.
If I use a mozilla.org build before the 27th of february, I don't have the performance regression.
A build from mozilla.org after the 27th of february has the performance regression.

Here are 3 videos, showing the problem:

1) Smooth: attachment 616108 [details] - Firefox, before February 27th - mozilla.org build

2) Slow: attachment 616106 [details] - Firefox Nightly (April) - mozilla.org build

3) Smooth, almost as good as 1): attachment 616107 [details] - Firefox Nightly (April) - my own build


======== 1) mozilla.org build (April) =======


about:buildconfig
Build Machine

linux64-ix-slave16
Source

Built from http://hg.mozilla.org/mozilla-central/rev/28ebf87f14a9
Build platform
target
x86_64-unknown-linux-gnu
Build tools
Compiler 	Version 	Compiler flags
/usr/bin/ccache /tools/gcc-4.5-0moz3/bin/gcc 	gcc version 4.5.2 (GCC) 	-pedantic -Wall -Wpointer-arith -Wdeclaration-after-statement -Werror=return-type -Wtype-limits -Wempty-body -Wno-unused -Wno-overlength-strings -Wcast-align -Wno-long-long -fno-strict-aliasing -ffunction-sections -fdata-sections -pthread -pipe -DNDEBUG -DTRIMMED -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3 -fomit-frame-pointer
/usr/bin/ccache /tools/gcc-4.5-0moz3/bin/g++ 	gcc version 4.5.2 (GCC) 	-fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -Wno-long-long -fno-exceptions -fno-strict-aliasing -std=gnu++0x -ffunction-sections -fdata-sections -pthread -pipe -DNDEBUG -DTRIMMED -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3 -fomit-frame-pointer
Configure arguments

--enable-update-channel=nightly --enable-update-packaging --enable-codesighs --enable-signmar --enable-js-diagnostics --enable-stdcxx-compat --enable-warnings-as-errors --with-ccache=/usr/bin/ccache

======== 2) mozilla.org build (February) =======

about:buildconfig
Build Machine

linux64-ix-slave08
Source

Built from http://hg.mozilla.org/mozilla-central/rev/cd4853b0b94a
Build platform
target
x86_64-unknown-linux-gnu
Build tools
Compiler 	Version 	Compiler flags
/usr/bin/ccache /tools/gcc-4.5-0moz3/bin/gcc 	gcc version 4.5.2 (GCC) 	-pedantic -Wall -W -Wno-unused -Wpointer-arith -Wdeclaration-after-statement -Wcast-align -W -Wno-long-long -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3 -fomit-frame-pointer
/usr/bin/ccache /tools/gcc-4.5-0moz3/bin/g++ 	gcc version 4.5.2 (GCC) 	-fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -fno-exceptions -fno-strict-aliasing -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3 -fomit-frame-pointer
Configure arguments

--enable-update-channel=nightly --enable-update-packaging --enable-codesighs --enable-js-diagnostics --enable-stdcxx-compat --with-ccache=/usr/bin/ccache --enable-warnings-as-errors


======== 3) my own build =======


about:buildconfig
Build Machine

localhost
Build platform
target
x86_64-unknown-linux-gnu
Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 4.6.3 (GCC) 	-pedantic -Wall -Wpointer-arith -Wdeclaration-after-statement -Werror=return-type -Wtype-limits -Wempty-body -Wno-unused -Wno-overlength-strings -Wcast-align -Wno-long-long -fno-strict-aliasing -ffunction-sections -fdata-sections -pthread -pipe -DNDEBUG -DTRIMMED -g -Os -freorder-blocks -fomit-frame-pointer
c++ 	gcc version 4.6.3 (GCC) 	-fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -Wno-long-long -fno-exceptions -fno-strict-aliasing -std=gnu++0x -ffunction-sections -fdata-sections -pthread -pipe -DNDEBUG -DTRIMMED -g -Os -freorder-blocks -fomit-frame-pointer
Configure arguments

--enable-chrome-format=symlink --disable-gconf
significant differences in those options include:

options in Apr not in Feb (gcc):

/*
-Werror=return-type,-Wtype-limits,-Wempty-body,-Wno-overlength-strings,-ffunction-sections,-fdata-sections
*/

options in Feb not in Apr (gpp):

/*
-Wsynth,-Wno-non-virtual-dtor
*/

options in Apr not in Feb (gpp):

/*
-Wtype-limits,-Wempty-body,-Wno-overlength-strings,-ffunction-sections,-fdata-sections
*/

make options in Apr not in Feb:

/*
--enable-signmar
*/

No mk options in February not in April.

We should probably ask ... someone about these. CC'ing, bz and taras to help make sense of this.

Check my work!
---

/*
 * This is a JavaScript Scratchpad.
 *
 * Enter some JavaScript, then Right Click or choose from the Execute Menu:
 * 1. Run to evaluate the selected text,
 * 2. Inspect to bring up an Object Inspector on the result, or,
 * 3. Display to insert the result in a comment after the selection.
 */

let gccFeb = "-pedantic -Wall -W -Wno-unused -Wpointer-arith -Wdeclaration-after-statement -Wcast-align -W -Wno-long-long -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3 -fomit-frame-pointer";
let gppFeb = "-fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -fno-exceptions -fno-strict-aliasing -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3 -fomit-frame-pointer";

let gccApr = "-pedantic -Wall -Wpointer-arith -Wdeclaration-after-statement -Werror=return-type -Wtype-limits -Wempty-body -Wno-unused -Wno-overlength-strings -Wcast-align -Wno-long-long -fno-strict-aliasing -ffunction-sections -fdata-sections -pthread -pipe -DNDEBUG -DTRIMMED -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3 -fomit-frame-pointer";
let gppApr = "-fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -Wno-long-long -fno-exceptions -fno-strict-aliasing -std=gnu++0x -ffunction-sections -fdata-sections -pthread -pipe -DNDEBUG -DTRIMMED -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3 -fomit-frame-pointer";

let mkFeb = "--enable-update-channel=nightly --enable-update-packaging --enable-codesighs --enable-js-diagnostics --enable-stdcxx-compat --with-ccache=/usr/bin/ccache --enable-warnings-as-errors";
let mkApr = "--enable-update-channel=nightly --enable-update-packaging --enable-codesighs --enable-signmar --enable-js-diagnostics --enable-stdcxx-compat --enable-warnings-as-errors --with-ccache=/usr/bin/ccache";

let gccFebOpts = gccFeb.split(" ");
let gppFebOpts = gppFeb.split(" ");

let gccAprOpts = gccApr.split(" ");
let gppAprOpts = gppApr.split(" ");

let mkFebOpts = mkFeb.split(" ");
let mkAprOpts = mkApr.split(" ");

let optsInFebNotInApr = gccFebOpts.filter(function(opt) {
  return gccAprOpts.indexOf(opt) == -1;
});

/*
-W,-W
*/

let optsInAprNotInFeb = gccAprOpts.filter(function(opt) {
  return gccFebOpts.indexOf(opt) == -1;
});

/*
-Werror=return-type,-Wtype-limits,-Wempty-body,-Wno-overlength-strings,-ffunction-sections,-fdata-sections
*/

let optsGppInFebNotInApr = gppFebOpts.filter(function(opt) {
  return gppAprOpts.indexOf(opt) == -1;
});


/*
-Wsynth,-Wno-non-virtual-dtor
*/

let optsGppInAprNotInFeb = gppAprOpts.filter(function(opt) {
  return gppFebOpts.indexOf(opt) == -1;
});

/*
-Wtype-limits,-Wempty-body,-Wno-overlength-strings,-ffunction-sections,-fdata-sections
*/

let mkOptsInFebNotInApr = mkFebOpts.filter(function(opt) {
  return mkAprOpts.indexOf(opt) == -1;
});


/*

*/

let mkOptsInAprNotInFeb = mkAprOpts.filter(function(opt) {
  return mkFebOpts.indexOf(opt) == -1;
});


/*
--enable-signmar
*/
Keywords: regression
Keywords: perf
(Assignee)

Comment 42

7 years ago
I will make a try build of 85e309ee6d34, to make sure it is not related to devtools code.

Also, Mike Hommey mentioned that a difference between my build and mozilla's build is that I don't have PGO.
we don't ship PGO builds on Mac.
(Assignee)

Comment 44

7 years ago
(In reply to Rob Campbell [:rc] (:robcee) from comment #43)
> we don't ship PGO builds on Mac.

So far, we found a performance regression only on Windows and Linux. We didn't test on Mac yet.

Can someone with a Mac test this:
- download a build from the 26th of February: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/02/
- reproduce the test see here: attachment 616108 [details] (http://news.ycombinator.com/)
Yes, but the bug report was on Windows and Paul is reproducing on Linux.

That said, I would be very surprised if PGO really causes problems.

Can someone give me detailed steps to reproduce please?  Comment 35 is not that helpful for someone not familiar with our devtools or with what this "highlighter" thing is....
(Assignee)

Comment 46

7 years ago
STR:
- open http://news.ycombinator.com/
- starts the highlighter: Menu Web Developer > Inspect
- move the mouse to the first item of the page, on the right of the triangle
- move the mouse quickly 500px down

Expected result:
- most of the hovered elements on the path of the mouse are highlighted

Actual result:
- only a couple of them are

See an example here:
- Smooth: attachment 616108 [details]
- Slow: attachment 616106 [details]

----------------

In the regression window: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d1b2fd680235&tochange=7ce4d9b55863
We see some Highlighter related changes. So we thought it was directly related.

But I can't reproduce here with my own build (see comment 40). This is why I am also looking at build system and PGO changes (if any, I don't know anything about PGO)
Hmm.  I can't seem to reproduce the really slow behavior on either a nightly or my own build, but that's on Mac.

But in terms of comment 29, hasPseudoClassLock is not a large part of the time I do see spent.  I see about 45-50% painting, 10% appending DOM nodes, 5% removing DOM nodes, 6% flushing layout and style to get bounding  client rects, 5% calling mozInnerScreenX (which again flushes layout on something), and various JS execution bits.  The total time spent calling HasPseudoClassLock, on the other hand, is somewhere around 0.2% of total time.
(Reporter)

Comment 48

7 years ago
Also confirmed on Firefox 13 stable.
(Assignee)

Comment 49

6 years ago
I found the problem. This will be fixed in bug 770818.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 770818

Updated

6 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.