1490798 - Long Ion compiles during Google Docs loading

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect, P2)

Description

[Markus Stange [:mstange]]

There's a 196ms compile and a 63ms compile in this profile: https://perfht.ml/2x4sYWG

This was recorded while loading the document in bug 1488435 comment 3.

Comment 1

[Nicolas B. Pierron [:nbp]]

This issue should be addressed by Bug 1396822 and Bug 1454586.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Any updates here, nbp?

Comment 3

[Nicolas B. Pierron [:nbp]]

This is not addressed and was not a priority prior to the qf:p1:pageload changes.

Bug 1489142 should have addressed some of the issues seen with branch pruning inefficiencies, but it has not yet been moved to the main thread (Bug 1396822).

Jan and I recently discussed on IRC (Bug 1540935) on what would be a better design for our resume points, which is now blocking Bug 1454586.

However, I suspect this issue should be less of a problem now that we have multiple tiers of IonMonkey's compilation (Bug 1382650).
The problem will still occur, but it is less likely to appear during the page-load.

Comment 4

[Kannan Vijayan [:djvj]]

This needs to be re-measured after jandem landed the changes to Ion compile tunings and tiering. I suspect this bug can be closed as fixed.

Comment 5

[Kannan Vijayan [:djvj]]

Sorry for the needinfo mconley - spurious.

Comment 6

[Caroline Cullen [:caroline]]

Profile rerecorded on the same document load from bug 1488435 comment 3 on a comparable machine: https://perfht.ml/2T7MPy2.

The longest Ion compile is 137 ms as compared to the previous profile which showed an Ion compiler of 195 ms. I do not know if tiering had the same effect on performance that was originally expected.

Comment 7

[Jan de Mooij [:jandem]]

(In reply to Caroline Cullen [:caroline] from comment #6)

The longest Ion compile is 137 ms as compared to the previous profile which showed an Ion compiler of 195 ms. I do not know if tiering had the same effect on performance that was originally expected.

The performance effect on GDocs is definitely there (bug 1382650 comment 20 has numbers), but it's true that it doesn't fix all long compiles. It was more of a short-term stopgap to alleviate the problem significantly.

Comment 8

[Kannan Vijayan [:djvj]]

A measure of the general distribution of compile times before and after would be the right thing to do here. GDocs is one of those sites that will exercise some code very heavily and will definitely end up hitting the 4th tier, and induce "bigger" compiles.

The best visualization I can think of for this is to collect all Ion compiles and sort them by both start-time and length of compile. The trend from before patch to after patch should be that the bigger compiles get pushed "back" (further away from page load), and overall become shorter.

What we should see is the center of the distribution move, and the distribution itself become bimodal across the 3rd tier Ion compile and the 4th tier Ion compile.

Comment 9

[Sean Feng [:sefeng]]

During the bug bash week, Nazim collected a new profile https://share.firefox.dev/3dXn2Vs, and it turned out this is no longer an issue.

Closing this one out.