1385430 - Searching in large scripts in debugger hangs browser

Status: NEW

(DevTools :: Debugger, defect, P3)

Description

[Ted Campbell [:tcampbell]]

STR:
- Go to netflix.com
- Open devtools debugger
- Find script codex.nflxext.com -> 2.0.0/truthbundle -> akira -> common/bootstrap.js
- Ctrl+F to search source code
- Type 's' 't'

Expected: Able to find strings in source
Actual: After first letter, the browser hangs until a slow script dialog pops up.

I see a lot of time in JS, but we should make sure we aren't doing something silly in debugger too.

BONUS: When the slow-script dialog appears, pressing the debug button will break your browser by leaving you in a nested modal state. Everything reflows correctly, but can't interact with the UI at all.

Comment 1

[Ted Campbell [:tcampbell]]

(Me or someone from JS should look if the JS portion is worth fixing)

Comment 2

[Ted Campbell [:tcampbell]]

Profile: https://perfht.ml/2uGaFXr

Comment 3

[Ted Campbell [:tcampbell]]

This might be a dupe of Bug 1384536.

Comment 4

[Jason Laster [:jlast]]

Hi, :tcampbell could you try again? I believe :yulia fixed it last month here (https://github.com/devtools-html/debugger.html/pull/3885)

Comment 5

[Ted Campbell [:tcampbell]]

It is much faster than it was. I still see 3+ second pauses for simple searches in the example from Comment 0. This is in contrast to opening source view in another tab and using search-in-page which behaves near instantly.

Here is current profile https://perfht.ml/2yw0hjS

One thing that standouts out is |updateHeightsInViewport| seems to cascade into very expensive reflows. I wonder if this is avoidable.

Comment 6

[Jason Laster [:jlast]]

Thanks :tcampbell, I'll share this in our github issue (https://github.com/devtools-html/debugger.html/issues/4189). I had forgotten that we created a new search perf issue in GH :)

Comment 7

[Jason Laster [:jlast]]

Ted, could you test this and see how this is now?

Comment 8

[Ted Campbell [:tcampbell]]

I'm seeing 1 second pauses now which is an improvement over Comment 5. It isn't a pleasant developer experience, but it does at least get results. I notice on the github you experience it as being fast on the Netflix test case. Is it significantly better than 1s per letter for you?

Comment 9

[Jason Laster [:jlast]]

Thanks!

Here is a profile http://bit.ly/2TkNnjL. It looks like we're asking a lot of the DOM to add/remove a bunch of these markers if there are 100+ markers. I think we could be better in two ways:

1. draw the markers that are visible - we do this for column breakpoints
2. remove/add markers in the same operation.

I'm going to move it to a P3 as it is not a priority at the moment.