Search Unity

Feedback Please add filtering options to the Profiler

Discussion in 'Editor & General Support' started by xVergilx, May 25, 2020.

  1. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    As project grows, it becomes more and more tedious to navigate Profiler.
    Please add filters for the Profiler.

    Mainly I'm interested in excluding calls of the methods from the displayed hierarchy, to keep vital information only.
     
  2. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,457
    Hi,
    Thanks for the feedback. We've heard different wishes on how people would like to filter the Profiler data so I'd like dig a bit deeper here.
    I'm assuming you mean the CPU Usage profiler module, specially its detailed views (Timeline and Hierarchy)? Is this view specific, i.e. Timeline Or Hierarchy or both? Do you mean Deep Profiling data or non deep Profiling data too?
    What part of this becomes tedious to navigate? Is it the performance of the UI or the depth of the sample stack?

    How would you imagine this Workin? Would you want to e.g. right click on a call to exlude it? Would that drop just that sample or also all of its child samples, adding their self times to the parent sample of the excluded one? How long should that exclusion persist? Should it persist machine wide or only this project? Just for you or also for your colleagues? Are there some assemblies or specific samples you'd general want to/not want to see or even collect data from? Would you want to only deep profile some scopes or exclude some scopes from deep Profiling? If so, would that be acceptable to configure in code via specific Profiler marker like markup or should that be from UI?

    Note: any kind of filtering for deep profiling or not deep Profiling in a scope would potentially add some small overhead to all deep Profiling samples. Would that make it less attractive?
     
    xVergilx likes this.
  3. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    Hi
    Yes, its Hierarchy / Raw Hierarchy (CPU).

    Both non-deep and deep profile data.

    Its hard to pin-point optimization problems in the Editor with stuff like .GetComponent allocating strings, legacy GUI, SendEvents calls, etc.
    In build there's stuff that is project specific that cannot be optimized anymore beyond changing algorithms, which just an information that is not really helpful to scrollthrough, navigate and analyze each time on the frame switch.

    So it gets even worse when switching to the different frames.
    Prev / Next -> Scroll -> Attempt to find issues -> Skip bunch of useless calls -> repeat.

    Raw hierarchy makes it even worse.

    Personally, I'd be more than happy with the Right Click -> Exclude and a separate sub-window to display excluded calls (their count). Or a wildcard by name exclusion via inputfield. Or both.

    In hierarchy mode it could be displayed between children as *excluded calls*, or excluding children as well. Call count is probably useful to keep in this case.

    About time (ms) or GC it would be nice to recalcalulate it based on the displayed calls only.
    If that's too tricky to implement - its okay, not a big deal.

    Configuring in code is probably an overkill, but it would be nice to have some custom markup in the future.


    TL;DR: Its all about excluding calls from being displayed.
    Trimming down useless expected information to analyze samples faster and speeding up the workflow.


    Persistence should last until subset is cleared.
    Well anything that persists between domain reloads are good enough for me.
    EditorPrefs would probably be an overkill, so something project per local machine wide is more than enough.

    To be honest, Deep Profiling isn't that fast to run on the machine with the Profiler running on top.
    So I doubt it will make it that much worse. Usability is always a win though.
     
    Last edited: May 25, 2020
    Bedtime and alexeyzakharov like this.