1200483 - Performance issue for DXR context menu

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Xidorn Quan [:xidorn] UTC+10]

When viewing a huge cpp source file (e.g. nsCSSFrameConstructor.cpp) in DXR, if you click any identifier, you would notice an annoying lag.

According to the info from performance tools, that is mainly because of two long layout, the first is triggered by getting `window.scrollY`, the second is triggered by some element`.focus()`.

Visually the script does two things:
1. hightlight all matches of the identifier
2. show/hide the context menu

None of them should triggers layout for the whole page as far as I see.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> 1. hightlight all matches of the identifier

Is this done by modifying the DOM?

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

Hmm, good catch. It seems they do that via wrapping nodes with <mark> tag. [1] I thought they should use class or attribute...

[1] https://github.com/mozilla/dxr/blob/16c97e2a3697ea700b361a09b9841478049ab148/dxr/static/js/context_menu.js#L17

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

But Blink performs much better than ours on that case. It takes only ~50ms for that layout, while ours takes >1s in total.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Sure.  So we need to profile.

Comment 5

[Xidorn Quan [:xidorn] UTC+10]

http://people.mozilla.org/~bgirard/cleopatra/#report=1d6f47780d001124edc03f32be1b091303c11317&filter=[{%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A65647,%22end%22%3A70482}]&selection=0,4290,4291,4292,4293,4072,4294,8,9,179,180,181,182,183,184,185,186,229,151

Comment 6

[Boris Zbarsky [:bzbarsky]]

Hmm.  I'm seeing a lot of table reflow in that profile...

Comment 7

[Xidorn Quan [:xidorn] UTC+10]

From the profile, it seems there are two parts which takes the most of the time:
* the reconstruction of the table (~14% in reconstruction + ~16% in reflow)
* reflow of float elements. Roughly ~40% of the time is spent on the single function nsFloatManager::GetFlowArea(), within which half happens before the reconstruction, and half after.

It seems in DXR, every line of code is a float element, which may be one of the main reason of the slowness.

Comment 8

[Xidorn Quan [:xidorn] UTC+10]

It seems this is no longer a big issue on Nightly. Probably has been fixed by some other bugs. Close with WORKSFORME.