Exclude function (or category, or library) from call tree

[hotsphink]

I would like to be able to filter out a given function from the call tree, by name or substring. My use case: ignore anything that ends up calling __poll.

Expanding beyond this, it'd be nice to filter out everything matching a given category (or set of categories?). Or everything in a certain library (eg libnspr4.so).

It might be nice to omit it from the whole display -- in order for the time to still match other threads, you'd have to replace those samples with a "missing data" color or something.

[gregtatum]

I feel like we need a generic and transparent way to add and remove filters. Ehsan wants to be able to apply multiple searches. I feel like there is a generic solution here to these types of things. @mstange do you have thoughts here?

For instance as a user I'd like to use the search box and add a search term, add this as a filter, then do this again. Then I'd like to go to the calltree, and choose something like mach_msg_trap, right click it, and choose, "hide this callstack". Then I'd like to be able remove filters easily. Maybe there is a dropdown that lists all the filters currently being applied?

[hotsphink]

I didn't want to overload this bug, but I was thinking about extensions in two different directions related to this. I'll put them down in case they spark any ideas.

First, I would like to have "lenses" (for lack of a better term) that would map frames to other things. A simple example would be a lens that showed the category of a frame, probably collapsing adjacent things with the same category in order to produce a vastly simpler call tree (or timeline). It might be all or nothing, or only apply partially (eg map everything in libnspr4.so to the library name but leave libxul.so stuff with the original function names.)

Example lenses might be categories, libraries, toplevel source directory names, nearest containing pseudoframe (equivalent to filtering out all native frames), mapping frames of a certain type to data associated with the frame (the IPC message involved, or the URL loaded, or the type of garbage collection -- whole heap vs a subset), or addon names.

It's all horribly complex, both in implementation and interface, which is why I hadn't bothered filing an issue for it. The purpose is mostly to cut out a lot of clutter irrelevant to a given situation to narrow in on the relevant portions of what is happening.

Second, orthogonal but related to the first, is a general workflow for brutally trimming down a profile to demonstrate a particular thing. This would be intended for profile sharing, where you want to describe a performance issue to somebody else by giving them a link that shows them exactly what they need to know without requiring them to deeply understand the profiler interface themselves and navigate through to find out what's going on. It would require a lot of the sort of repeated filtering that you were talking about, plus maybe hiding processes and threads (or highlighting the others). You could still take off the filters or whatever in order to see the underlying data in more detail, or do your own investigation, but it would be a higher bandwidth way of communicating a perf problem to someone.

Again, complex and vague, so I haven't bothered filing an issue for it.

[mstange]

I've had thoughts along very similar lines as sfink, and they're not very concrete either.

The callstack filter breadcrumb bar was intended to be a list of all types of filters that apply to the call tree. But it currently imposes a hierarchical relation between these filters, whereas some of them might be orthogonal to each other.

[clarkbw]

Likely blocking on the work in #435

[gregtatum]

@hotsphink this bug got closed with the "drop function" transform #693. If you want to re-file your other ideas here feel free.