When running profiling against a codebase, sometimes the developer might want to filter out (or in) specific parts of the codebase that are of no interest when analyzing the profiling results.

Example: codebase uses a vendor library that pollutes the profiler output with numerous but performant calls and loops. This makes it hard to find and analyze the developer's own code, without creating a redundant setup where code is generated only to make profiling it simpler.

For instance, I run PHPUnit tests and want to profile my own test cases, not the PHPUnit bootstrapping and boilerplate code.

I am not sure if this is even remotely possible, as I am not versed in how valgrind/callgrind/cachegrind formats work, or how those are implemented in Xdebug. In the end I would love to see a config value similar to

xdebug.profiler_ignore_paths=/path/to/files/,/path/to/single/file.php,/path/with/*/wildcard

Or should I look into finding tools that operate on finished grind outputs? I know Xdebug has a feature for aggregating multiple dumps into one, so the format should be somewhat workable after profiling runs themselves?