1594565 - Treeherder spends a 2+ seconds in JS

Status: RESOLVED DUPLICATE of bug 1499551

(Tree Management :: Treeherder, defect, P2)

Description

[Jeff Muizelaar [:jrmuizel]]

Here's a profile:
https://perfht.ml/36HaH1W

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Armen, here's the performance problem I was complaining about.

Comment 2

[Armen [:armenzg]]

Hi Jeff,
Thanks for filing!

I will ask camd to see if from looking at it he can figure out what's happening as he's more familiar with

What is the impact you notice? Do you notice UI slow downs? What repos did you have open at the time?
How does it impact your work?

I'm not familiar with reading profiles.
How do I understand the yellow bar with orange peaks?

I see that the mapPushJobs takes 65% of the time for a promise. I believe this code is the one related to updating all jobs in the UI. I assume this is worse with # of pushes loaded on a page.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

I believe this was happening on a tab with autoland open. While this happening the process that it's happening in becomes basically unusable. This means other tabs in the same process also become unusable.

The basic information to get from the profile is that handleApplyNewJobs is taking a really long time (or being called a large number of times) and it perhaps gets worse over time. Perhaps there's something that's accidentally quadratic?

Comment 4

[Cameron Dawson [:camd]]

I will take a look at this when I've cleared a couple other things off my plate.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Please note that the profile from comment 0 doesn't show any data anymore. Julien any idea why that is the case?

Comment 6

[Julien Wajsberg [:julienw]]

Ah, that's interesting, I believe https://github.com/firefox-devtools/profiler/pull/2332 made that happen.
Long story short: during a few weeks we were calculating the range using both markers and samples (previously we were computing the range using samples only). The goal was to support profiles containing only markers.
But we realized this brought a few side effects, because it's common that profiles have markers that are positioned in an awkward position, the result was that the initial view was weird. So we reverted the change when we had samples.

But we didn't pay attention that this could make the range "saved" in some URLs completely wrong. This is probably too late to change this now, sorry :/ Also very probably this also made some even older URLs work again...
The workaround is then to move back to the full view (click "full range" at the top left), and possibly select a new range. Most likely you won't need to select a new range thanks to the revert I mentioned above.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Thanks for the explanation, and sorry that I missed the "full range" part. It's not that observable. But now it works!

So 70% of the time it spends in ca/this.handleApplyNewJobs.

Comment 8

[Cameron Dawson [:camd]]

De-prioritizing Treeherder work in new reorg. So removing myself.

Comment 9

[Florian Quèze [:florian]]

The profile is similar enough to what we have in bug 1499551 that I will call this a duplicate.