option to allow users to split heatmap by thread

[bobrik]

Currently there seem to be the only mode with seconds on X axis and 20ms buckets on the Y axis.

I'd like to suggest a mode with threads on the Y axis and smaller buckets on the X axis.

My real world usage is ClickHouse. We have loads of data in our instances and they take quite a bit of time to both start up and tear down. During that time we can observe only some low number of cores being saturated.

With the proposed mode we'd be able to see which threads are doing what and when. This mode should work nicely with specialized thread pools.

[brendangregg]

There's a huge benefit at fitting all the data on one screen. We have apps with 1000 threads, and 10,000 threads, and that many rows won't fit. I'd consider such a heat map if it showed "top 100 threads" only for a 100 row heat map -- the current row selector can be used to select how many should be included in the top. The "top" threads will be based on those that have the highest total counts.

Note that this thread visualization would break vertical proximity -- a block in one row may be unrelated to what's happening above or below it. The selection code would also need to support a different type, since it's currently for subsecond offset heat maps.

I'd like to see a prototype and some solved problems.

[spiermar]

Agree with @brendangregg. I see this as a secondary view, that could be triggered by a UI option. This would be specially useful for some mobile OSs where the main thread has a completely different behavior than other threads.