1853284 - Netmonitor search is quite slow

Status: NEW

(DevTools :: Netmonitor, defect, P2)

Description

[Zhai Can]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0

Steps to reproduce:

1. Open Devtool "Network" panel
2. Go to https://bilibili.com (just an example site here)
3. Navigate the website (scroll down the page), making the devtool shows "~15MB transferred" at the bottom
4. Press Ctrl+Shift+F to do global search
5. Type some random string in the input box
6. Enter to search

Actual results:

It shows "Searching..." and a progress circle and keeps for a VERY long time. It doesn't seems to finish in a finite time (precisely it can, but just >10 minutes), and makes it totally unusable In practice.

Expected results:

It should display the result in seconds. The search has no reason to elapse so long for computers; I expect it will perform just as grep <some string> xx.har.

Additional notes:
If I save all these as a HAR file, re-open the browser plus import the HAR file (maybe need a small amount of wait), then do the global search again, it will become faster and CAN finish its search in sub-second, which is considered as a normal state.

Issue is present in Firefox 117 and 119.0a1.

Comment 1

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

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

Comment 2

[Hubert Boma Manilla (:bomsy)]

Thanks for reporting.

We can reproduce the issue. We'll profile & investigate and see how we can improve this.

Hi Tom,
Is this issue something you have come across while using the netmonitor search for webcompat investigations??

Comment 3

[Alexandre Poirot [:ochameau]]

The search code is here:
https://searchfox.org/mozilla-central/rev/7499890dc8f116a9e40f4a689a251a0311a9f461/devtools/client/netmonitor/src/actions/search.js#41-99

It suffers from the same issues as in the debugger which are being fixed in bug 1824393.
This code involves trigerring many redux action, leading to many redux state changes and possibly causing many react updates.
But this may not be the biggest source of trouble here.

The obvious one is about fetching all request data from backend to the frontend in order to do the search, that, including the response content which can be very large and cause lots of GC overhead.
Moving the search to be done on the backend would be the most effective way to optimize this, but may also be not so trivial.

Otherwise, this particular function may easily throw at any point when processing lots of data around each individual request.
This may lead to confusing UI state, with never finishing search.

Comment 4

[Thomas Wisniewski [:twisniewski]]

Yes, I do use this search a fair bit while diagnosing webcompat issues, and I have run across these kinds of symptoms before.