suggestion: timeline views

[graydon]

A helpful capacity in diagnostic tools like this is to be able to switch, while exploring the data, between the aggregate view (top, histogram, etc) and a sequential/timeline view that shows, for example, the scheduling events of {all,selected} {tasks,resources}, possibly with the option to interleave trace messages or similar user event annotations.

Often there's a bit of back and forth between these, like "find problem task in aggregate view, switch to timeline of task events, find problem resource, switch to timeline of resource, switch to timeline of all tasks contending on that resource"

[hawkw]

This is definitely something I'd really like to see as well! The focus for the prototypes/MVP so far has been on inspecting the current state, since that's comparatively simple to get working. But, displaying data over time is absolutely one of our long term goals!

Showing a timeline of what tasks have contended on/been notified by a particular resource is a great suggestion — I actually hadn't thought of that in particular yet, and it seems like something we can start doing fairly easily once resource instrumentation is fully plumbed through into the console. Thanks for the idea!

[seanmonstar]

We do have much of the "data" already, since the console is essentially just interpreting a series of events from tracing about task polls and wakes with timestamps. The "hard" part is figuring out what the design should look like. Any suggestions of existing tools/views would be very helpful :)

[graydon]

Oh, nothing too fancy. I think it's more of a "list and filter" problem than deep info-vis.

I'm pretty fond of the per-thread "narrative view" and its various event and summary support views, in macos Instruments.app. It has a couple visual proportional-use-of-time timelines ("os fundamentals" -- system calls, VM faults and thread states) along the tracks above, a minimal call stack for "whatever event is currently selected" down the right hand side, and a main area showing timestamped "next event that happened" lines.

The visual timeline is nice for a sort of "gut feel for how load shifts over time / which threads are busy doing what" impression, and it can be used to shift the narrative or event views on a particular region or egregiously-large event by clicking. But the main detail-action is in the narrative / event list in the middle of the screen:

Narrative view mixes together 4 different "event views": thread-state transitions, context switches, system calls and VM events. You can switch to each of those individually if you want each presented in a filtered and slightly-more-tabular form:

Each event view is paired with a summary view, and switching back and forth between summary and event is just flipping that combobox. So if you don't see anything obvious in narrative, you can switch to (say) syscall summary view:

and selecting an element from it you get a little filter-arrow:

which if you click on it, you'll jump back to the syscall event view:

at which point you can filter by the objects involved in the syscall:

which just narrows the set of events shown in that view:

Pretty much anything can be used to filter down the event view. That's one of the key aspects of it -- it's a browsable form of "strace + grep" -- so like if you click on any of the text in the notes or narrative view, it'll let you filter by that thing:

There's a stack of active filters in the lower left corner at any moment:

[hawkw]

I am also a big fan of the macOS Instruments UI --- it's one of the biggest things from the Mac that I miss on Linux. :)

I was thinking about the UI design for this as well, and I think the horizontally-scrolling design of Instruments' UI may not make as much sense in the terminal, if we want the user to be able to use the terminal's native scrollability to scroll through the history (although we could also implement our own scrolling behavior). I was wondering if it might make more sense to take a similar UI concept, but rotate it 90 degrees to scroll vertically...

[graydon]

I don't know that the horizontal splotches-and-bars tracks (or a vertical version thereof) is the killer feature, really. It's a nice sort of attention-directing indicator, I don't know that it's worth stressing over.

Like maybe focus on the event view and just .. put a "magnitude" column in that visually cues the user about how big a timeslice they're looking at while scrolling (eg. 4 chars * 8 width-subdivisions in the unicode box-drawing repertoire = 32 bins of log_2 magnitude)?

Something like:

mag	dur	state		note
██	50us	blocked		waiting for socket readiness on 0xf00
▏	1ns	running		
██	50us	blocked		waiting for socket readiness on 0xf00

Granted, log-scale is hard to intuit. Maybe linear scale plus a user-controllable zoom level? Shrug visual designer, I am not.