Add option to fill rows in timings graf based on jobs count

[panstromek]

Problem

Currently the timings graph is often very tall, but most of it is empty space, you have to scroll up and down a lot to get the full picture. You also don't see clearly where are empty time slots when threads are waiting.

Proposed Solution

It'd be useful to have an option to "squash" the graph in fewer rows (naturally to the number of jobs). Something like this, but correct (and more readable somehow):

Note: rows are allocated incorrectly on this picture, I just tried to do this naively with y = i % num_jobs.

Notes

No response

[panstromek]

I made a quick prototype of this (with option to hide labels, because it gets messy).

https://squash-timings-prototype.netlify.app/

If there is an interest in this, I can clean it up and open a PR.

[alexcrichton]

An interesting idea! I think the UI would need to be cleaned up a bit though. As you've mentioned with labels it's sort of hard to see but even without labels then it's sort of hard to figure out what's going on. I'm also curious about your example you linked was using 8 jobs but there are 9 rows, so I was wondering if there was presumably some heuristic you're using to map an invocation onto a row and whether it might be better to track that in the implementation by assigning job tokens numbers or something like that.

I think though that even a compact form of the graph can be somewhat misleading because open space doesn't necessarily mean something is waiting, it could theoretically be the case that rustc is doing parallel codegen and is taking multiple job slots at that time, but it's not reflected in the graph. This was the original intent with the CPU usage chart below where the CPU usage could be double-checked to ensure it's "full" and if it's not then the graph could be inspected for what was executing at that time.

[ehuss]

FWIW, the original prototype used this approach of only using one row per CPU. I found in most cases that it ended up being a solid wall of color, and couldn't see the relationships between jobs.

Raising the "Min unit time" just to 1 to 3s can make a huge difference in reducing the vertical height of the chart.

I'm happy to explore better ways to present the information. Presumably the question you want answered is "where are the bottlenecks"?

[panstromek]

I'm also curious about your example you linked was using 8 jobs but there are 9 rows, so I was wondering if there was presumably some heuristic you're using to map an invocation onto a row and whether it might be better to track that in the implementation by assigning job tokens numbers or something like that.

Yes, it's just a heuristic, as it's all done in JS, where no information about job tokens available atm. It just picks first row with free space, so it's probably just some rounding error. If I add a little tolerance for overlap, it will shrink to 8 rows. That said, I think it would be useful even for arbitrary number of rows, just to allow to shrink the graph to screen size at least.

I think though that even a compact form of the graph can be somewhat misleading because open space doesn't necessarily mean something is waiting, it could theoretically be the case that rustc is doing parallel codegen and is taking multiple job slots at that time

Yes, this information would be useful to have in the graph in general, but it's true that you can easily figure that out from CPU stats.

I'm happy to explore better ways to present the information. Presumably the question you want answered is "where are the bottlenecks"?

To be clear I think the default view is very useful and I wouldn't want to replace it, it's just that (at least for me), it's a bit easier to get a rough overview from the compact one, so It'd be cool to have the switch. It'd be better if codegen jobs were displayed too, though, as mentioned.