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: 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). A similar problem occurs for Date.Dispose: 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!). 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.