Bug: "Filter Out By Binary" cannot be stacked

[GitMensch]

Is your feature request related to a problem? Please describe.
Especially when recording system-wide or when otherwise recording multiple processes, for example via a shell script to get "combined results" as suggested in #464, you often end up with a profiling that includes not relevant system processes (for example bash, make, running compiles/link, ...).
Also when inspecting a "common" recording you may see two "big" functions that you are not interested in when checking the details.

Because of #4 and #292 we can filter by function/binary (works quite good and is often enough) or filter out a single function/binary.

Describe the solution you'd like
All "exclude" filters should "stack" automatic (a manual "reset filter" will be possible to empty the filter stack).
This allows for example to:

• filter in by binary INTEREST
• filter out by symbol A
• filter out by symbol B
  or:
• filter out by binary shell
• filter out by binary make
• filter out by binary cc1

Describe alternatives you've considered
For the binaries: record separately, then combine (as noted in the linked issue); but with the functions that still would be nice.

[milianw]

hey @GitMensch - I don't quite follow, the code does use stacks and matches multiple symbols and binaries. Maybe there's a logic bug in the code - can you give me an MWE of what you do where the filtering doesn't work the way you expect it to?

[GitMensch]

Rechecked with several single-process recordings and found all of this to work well there (filtering out by binary, for two shared objects, one after another, also testing further "filter in", also worked fine and did not bring the filtered out back).

Using a recent system-wide recording I see that "filter out by binary" seems to not stack (at least no in caller/callee, where I've tested):

order by binary -> filter out by binary on the first entry "bash" -> gone
order by binary -> filter out by binary on the now first entry "grep" -> gone, but "bash" is back

Edit: second test: system-wide recording, filter in by process (in the timeline), then using the Flame Graph to "filter out by binary 1" (gone), then "filter out by binary 2" (gone, but binary 1 is in again)

Just to recheck: Is there an option to "filter in by process" using multiple processes (for example after filtering in the timeline)? If not, should I open a new FR for that?

[GitMensch]

It is even worse.

• did a recording with perf record --call-graph dwarf,4096 --aio -z --sample-cpu --mmap-pages 16M
• converted it with /tmp/hotspot-v1.4.1-192-g73c5701-x86_64.AppImage --exportTo, which took around 3 minutes, flooding the console with "Invalid memory read requested by dwfl fffffffffffffff8" (op to ffffffffffffffff) as well as "No DWARF information found 24" (nearly all numbers up to 24) and seldom "no matching address range 2" (this message stands out as it starts lower case)
• opened hotspot, checked summary -> top hotspots per file - first one with 31.9%, second one as ?? with 25.2%
  
• executed "Filter out by binary" on the first entry, now gets back again as 45.5%, ?? gone
  
• no matter if re-executing the filter on the same file, or filter out the third one, the hotspots by file don't change any more

The "stacking filters" do work, I can go to the Caller/Callee tab and filter the symbols of this binary out, sadly this is not a good workaround as there is no multi-selection so I need to filter one by one and each time the dat ais recomputed. [Should I open a FR to allow multi-selection?]

So I'm quite sure that this specific filter "by binary" not working is the problem (a real bug) and the FR itself otherwise works fine -> adjusting the title.

[GitMensch]

Just rechecked with current appimage and a profiling of hotspot-perfparser.
It was tasked to handle a compressed perf recording so it was most reasonable to ignore the compression parts.

after "filter out by binary" libz:

after another "filter out by binary" libzstd: