Web Inspector: network log view refresh optimizations

• Component: Web Inspector (Deprecated)
• Status: RESOLVED FIXED

[Andrey Kosyakov]

This is a slight optimization of the way we update refresh network log view: now we create new rows off-screen, so that we spend less time when render tree is updated during updateOffscreenRow(). This also removes a redundant call to updateOffscreenRows() in refresh().

This reduces time for inspector/performance/resources/network-append-30-requests.html from ca 620ms to 590ms on my box.

[Andrey Kosyakov]

Created attachment 109038 [details]
patch

[Pavel Feldman]

Comment on attachment 109038 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=109038&action=review

> Source/WebCore/inspector/front-end/NetworkPanel.js:678
> +                node.element.addStyleClass("offscreen");

You should move this to where the element is accessible after creation: WebInspector.NetworkDataGridNode.prototype.createCells in your case.

> Source/WebCore/inspector/front-end/NetworkPanel.js:702
> +        // FIXME: evaluate performance impact of moving this before a call to sortItems()

Would be great to address it in this change. Note that while populating the log from scratch, wasScrolledToLastRow is always true. It might be that it is a noop though.

[Andrey Kosyakov]

Manually committ(In reply to comment #2)
> (From update of attachment 109038 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=109038&action=review
> 
> > Source/WebCore/inspector/front-end/NetworkPanel.js:678
> > +                node.element.addStyleClass("offscreen");
> 
> You should move this to where the element is accessible after creation: WebInspector.NetworkDataGridNode.prototype.createCells in your case.

Fixed!

> 
> > Source/WebCore/inspector/front-end/NetworkPanel.js:702
> > +        // FIXME: evaluate performance impact of moving this before a call to sortItems()
> 
> Would be great to address it in this change. Note that while populating the log from scratch, wasScrolledToLastRow is always true. It might be that it is a noop though.

it trquires a bit more of investigation (probably better benchmark) It's not a noop now, if I just move it to an earlier moment, we loose some 50ms.
I'm going to come back to this after extending the benchmark suite with profiling-like methods.

Manually committed r96318: http://trac.webkit.org/changeset/96318