1825270 - Performance issue (+ memory consumption) when using inspector search

Status: NEW

(DevTools :: General, defect, P2)

Description

[ekeek]

Attachment: firefox_memory_leak.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0

Steps to reproduce:

• visit a large page for example: view-source:https://en.wikipedia.org/wiki/List_of_Glagolitic_manuscripts
• open dev tools
• search tbody inside of page inspector

Actual results:

there is a large memory consumption

Expected results:

it should find tbody without issues

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Mayank Bansal]

I saw a 200MB memory increase when searching, and got this profile: https://share.firefox.dev/3LXibVB

Comment 3

[ekeek]

Comment on attachment 9325685 [details]
firefox_memory_leak.png

This is my profile: https://share.firefox.dev/3lKXqC5

Comment 4

[Julian Descottes [:jdescottes]]

Right, the view source markup for this page is huge, so doing a search in the inspector performs really badly.

We can look at the performance issue regardless, but is there a good reason to use the inspector search here? We are already on a source view, so I think you could directly use the built-in page search?

Comment 5

[Julian Descottes [:jdescottes]]

For reference, the markup of view-source for this specific page has 436415 elements.

Comment 6

[ekeek]

You are right, I've reported it because if it's reproducible maybe it can be a good test to investigate the memory leak, or maybe it's a my machine fault, Mayank's profile is not bad as mine.

Comment 7

[Julian Descottes [:jdescottes]]

Makes sense, and that's indeed a good test case to easily trigger the performance issue.

Comment 8

[Julian Descottes [:jdescottes]]

cc Emilio who is modifying this area at the moment, but we should definitely have a look once the code has been reshuffled.

Comment 9

[Alexandre Poirot [:ochameau]]

Yet another profile for comment 0 STR (doing three search for tbody):
https://share.firefox.dev/40H6UNX
Highlights many calls to nextNode itself spending what looks like an abnormal amount of time in isInXULDocument (it should probably be cached instead of being called so many times).

Also standardTreeWalkerFilter is called a lot and seems to spend lot of time in js::ProxyGetProperty.
May be we could fetch nodeName only once here?
https://searchfox.org/mozilla-central/rev/55d5c4b9dffe5e59eb6b019c1a930ec9ada47e10/devtools/server/actors/inspector/utils.js#136-142
Also, may be the order of these condition could be shuffled to be ordered to typical order of "positiveness".