Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

UI Elements - Performance Problems with DateTime

Discussion in 'UI Toolkit' started by sschoener, Oct 18, 2018.

  1. sschoener

    sschoener

    Joined:
    Aug 18, 2014
    Posts:
    73
    Hi there,

    I am currently writing an editor tool using UI Elements in the 2018.3.5b beta. First off -- it's so much faster to work with this than with IMGUI! That's super awesome!
    Now, my current problem is that I need to dynamically highlight parts of a Label element. This seems to be quite difficult because I need to split the Label into different parts whenever the highlighting term changes and set their styles accordingly. I already do all kinds of pooling etc. and have managed to bring the costs of that down significantly, but there are still performance problems. If you have any ideas for alternative approaches to dynamically highlighting text, I'm eager to hear them (the main performance culprit right now seems to be drawing the text components).

    During profiling, I stumbled on a curiosity: The UI elements code spends quite a lot of time with DateTime.Now. Now, everything I have measured is with Deep Profiling enabled and I am keenly aware of the problems with that, but DateTime.Now is well known to be a performance hog. The UI Elements system seems to pool events and call DateTime.Now each time you get something from the pool or release it. In one frame, this amounts to quite a few calls to that property and just caching that would solve the issue.

    As you can see below, the runtime of removing and adding elements is essentially driven by DateTime.Now:
    date-time-01.png
    The property is called twice (only one shown in the image, two calls for ReleasePooled and two for GetPooled) for each of them and in my case makes up about 8ms of each of the calls (RemoveFromHierarchy and SetParent).
    date-time-03.png

    A similar problem occurs for Date.Dispose:
    date-time-04.png

    Taking all of the accesses to DateTime.Now together shows that they take up about 17.7% of the total runtime (bear in mind all the problems with measuring with deep profiling which artificially blows up property getters due to its instrumentation, but DateTime.Now actually performs expensive work by itself, it's not just an accessor!).
    date-time-05.png

    I would appreciate it if you could look into this and maybe consider caching DateTime.Now in some sensible way :)

    Edit: And before you ask: Yes, I know that DateTime.Now is part of the framework and you cannot change it. But you *can* cache its result per frame or try to not call it when disposing to cut down on its costs etc.
     

    Attached Files:

    Last edited: Oct 18, 2018
    Selfmoon likes this.
  2. ShantiGaudreault

    ShantiGaudreault

    Joined:
    Aug 17, 2015
    Posts:
    9
    I'll let others talk to highlighting text.

    Regarding DateTime, good catch this is a must fix. We will do that and back-port.
     
  3. sschoener

    sschoener

    Joined:
    Aug 18, 2014
    Posts:
    73
    Thanks for getting back to me about this :) Fixing this will improve the performance quite a bit already.
     
  4. antoine-unity

    antoine-unity

    Unity Technologies

    Joined:
    Sep 10, 2015
    Posts:
    771
    The performance fix will be available in 2018.3.0b9 :)
     
    ow3n likes this.