Is your feature request related to a problem? Please describe. There are several recordings that I need to inspect without comparing the DB part (as that depends a bit on the server side / connection and is out of my scope). To achieve this I need to filter out several dso's and symbols each time. After re-opening a recording "of that type" I therefore apply the same filters.
Describe the solution you'd like Provide a (set of) command-line options to filter; using a plus sign as first, as would be using the + sign to "filter in" position could "filter in" to not need a duplicate set of command line arguments (which would be an alternative).
These filters would be stored globally and applied after the file is opened and parsed if necessary. Filtering on pid / tid would be useful when re-inspecting the same perfdata - less useful, but easy to implement with the same commit.
Suggestion:
--filter-binary [-]dso/path[,[-]dso/path ...]or--filter-dso [-]dso/path[,[-]dso/path ...]--filter-symbol [-]symbol[,[-]symbol ...]--filter-pid [-]pid[,[-]pid ...] --filter-tid [-]tid[,[-]tid ...]
Describe alternatives you've considered
A --filter-preset file[,file ...] option together with a GUI option to load (=adding) a preset and to store the current filter as preset.
Additional context I think I'd possibly be able to add the filtering command line options (not the preset one) and load them after opening a file, if no one else wants to do that. In any case having the specs first would be good. I'd have to check if it is easy to add a test for that, not sure.
Note: This does not conflict with #524 which is about filtering while creating the perfparser format (to reduce size and load time and to possibly also speed up the conversion) - that has a bunch of not yet clear questions for all but pid/tid filtering [which we therefore should split into a different, possible to achieve nowTM FR]. This FR is all about filter in the GUI only.
Activity
2
GitMensch9mo agoshould we allow exporting/importing of filters from the UI maybe, to simplify re-applying a certain state somehow?
That is the alternative idea with the "preset" - just define them once in the ui, allow to save (saves the current filters) and loads (add to the current filters, dropping duplicates) them from there.
I'm not positive that I can add that myself given heavy time constraints, adding the last part to those "a command line option to load them on startup" would be doable for me though.
I just wonder about the "these filters would be stored globally" - would they really be applied to all files or just the singular one file that you are opening from the CLI too?
It should be identical to other command line options, if I remember correctly things like --appPath are only applied to the initial file specified - if you open a new recording (maybe even when re-opening the existing one instead of F5?) then are dropped and only the settings from the UI are applied.
It should also be identical to normal loading - all filters are reset then. Providing the filter preset file would then allow to easily re-apply them, though, so with the second thought that may be the better option in any case while dropping the main benefit to specify them over and over again on the command line.
sounds like a valid request, patches welcome!
I just wonder about the "these filters would be stored globally" - would they really be applied to all files or just the singular one file that you are opening from the CLI too?
should we allow exporting/importing of filters from the UI maybe, to simplify re-applying a certain state somehow?