793942 - Figure out why the "offsetHeight triggers reflow" benchmark on robohornet is so slow

Status: RESOLVED DUPLICATE of bug 1387309

(Core :: Layout, defect)

Description

[Boris Zbarsky [:bzbarsky]]

Us:

offsetHeight triggers reflow	Completed successfully 	4537.98ms

Chrome:

offsetHeight triggers reflow	Completed successfully	495.35ms

Comment 1

[Boris Zbarsky [:bzbarsky]]

So I see a smaller gap on my setup (maybe 3x).  A lot of it is that ReResolveStyleContext 4 levels deep or whatever we get with the scrollframe takes time.  The rest is the whole scrollframe reflow business, with its post-reflow callback, second reflow from that, etc, etc.  If I just remove the overflow style, or set it to "hidden", our time here drops by a factor of 3.

The question is, do we care?  Should we maybe offer a patch to improve the test to test a more realistic situation?

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I would really like to have someone refactor the scrollbar code so that we have just a single frame representing the entire scrollbar. That would give a very small speedup for just about every single Web page, and would also help a lot here.

Comment 3

[Florian Bender]

Is Bug 645563 about what you asked?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes.

Comment 5

[xunxun]

On windows, the test call GetThemeBackgroundContentRect too many times, can we cache the api's results?

Comment 6

[Daniel Holbert [:dholbert]]

This subtest lives at http://www.robohornet.org/tests/offsetreflow.html (currently at least), and nowadays the gap between us vs. Chrome has narrowed as discussed in bug 1387309 comment 7. Also, this benchmark is abandoned/deprecated ("It had flaws and is abandoned.") as noted at https://github.com/robohornet/robohornet .

Duping forward to bug 1387309 (which I just closed), since both bugs are about the same sub-benchmark.