Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only. On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live. Read our full announcement for more information and let us know if you have any questions.

Animation Event performance degrades severely depending on amount of components on animated object

Discussion in '5.2 Beta' started by Sebioff, Jul 6, 2015.

  1. Sebioff

    Sebioff

    Joined:
    Dec 22, 2013
    Posts:
    218
    I noticed that the performance of Animation Events is... really bad.

    Here's a look at the profiler with 400 animated objects triggering an animation event within the same frame. The triggered method is entirely empty to make sure the lag spikes aren't caused by my own code:
    Bildschirmfoto 2015-05-24 um 12.53.56.png

    This screenshot is from a reproduction project, there's nothing running but the animations. It has been submitted as case #699102.
    What's worse is that animation event performance directly depends on the amount of components that are attached to the animated object, as the reproduction project demonstrates.

    And to show that this is not just a constructed worst-case scenario, here's a profiler screenshot from a real project:
    Bildschirmfoto 2015-07-06 um 23.21.27.png
    ~20ms per frame spent just triggering animation events o_O
     
  2. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,670
    Are you saying this is a regression from 5.1?
     
  3. Sebioff

    Sebioff

    Joined:
    Dec 22, 2013
    Posts:
    218
    Yes, sorry. At least partially, that is - I originally noticed and reported the problem in 5.0.2 (not sure if it's a regression from 5.0.1 or an even older problem), but it became significantly worse in 5.2 beta.

    Here's the profiler showing the same scene as in the second screenshot in the original post, but running in 5.1.1p1:
    Bildschirmfoto 2015-07-07 um 01.31.43.png
    ~9ms still seems excessive to me for what's more or less just a method call (and prohibits us from using animation events just as much in the end), but notice that this time at least doubled with 5.2 beta.

    Should I submit a separate bug report from within the editor for 5.2 beta?
     
    Last edited: Jul 7, 2015
    MrEsquire likes this.
  4. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,670
    Yes, please submit a new report - it could help to reference the previous bug number in the report, but it's generally helpful to have it confirmed that the problem still exists in a bleeding-edge version.

    Also, FWIW: the time taken here is almost certainly not going to be in the method call itself, but in locating the component(s) that the method call is implemented on. That's why it depends on the number of components; the more components you have, the more components it has to scan through, looking for methods.
     
  5. Sebioff

    Sebioff

    Joined:
    Dec 22, 2013
    Posts:
    218
    Alright! Submitted as case #710198 (for the future - should bugs generally be resubmitted for major new releases if they can still be reproduced? Or can old reports be updated somehow to confirm that?).

    Yeah...I suspect it's using reflection on all components to find the method that it needs to call, every single time the animation event is triggered...or something along these lines.
    I imagine automatically caching the method location could be tricky, since it needs to react to hierarchy changes/component additions/removals? Optionally caching it from within the Animator initialization/manually using an API call would be good enough for me. I suspect our project is one of the more extreme cases for this problem, but I hope I could show that solving this in some way would be very valuable.
     
    Last edited: Jul 7, 2015
    Ferazel likes this.
  6. Mecanim-Dev

    Mecanim-Dev

    Joined:
    Nov 26, 2012
    Posts:
    1,675
    Hi Sebioff,

    We are already working on a solution, like superpig said most of the time is lost for searching for each method in each component, unfortunately the solution won't be available for 5.2 because is too risky at this time of the release.
     
  7. Sebioff

    Sebioff

    Joined:
    Dec 22, 2013
    Posts:
    218
    Hey!

    Super happy to hear that it's been recognized and is being worked on, so that's alright! Thanks for the info :)

    Somewhat big unrelated question: do you think moving Mecanim off the main thread is a possibility in the long term? It's by far our biggest CPU cost at the moment (not unexpected with hundreds of characters of course).
     
  8. Mecanim-Dev

    Mecanim-Dev

    Joined:
    Nov 26, 2012
    Posts:
    1,675
    Most of mecanim is already multithreaded: Animation clip evaluation, Retargeting for human, IK evaluation and even the step to write the animated values into properties is multithreaded.

    The only thing left on the main thread is job scheduling and everything related with scripting: fire animation events, fire state machine behaviour, apply on animator move, apply on IK. There is some ongoing work to try to multithread scripting but as long as this is not ready we cannot move all mecanim off the main thread.

    mecanimmultithread.png
     
  9. imtrobin

    imtrobin

    Joined:
    Nov 30, 2009
    Posts:
    1,552
    Since we are on this topic, why are private methods available for Animation Events? For a production project, there are like 100 of private calls which are exposed, making setting AnimationEvent difficult. Just look at Third Person control sample, already alot of private functions.