Speeding up Unreal Editor launch by not spawning unused tooltips
1–10 of 92 posts
Re: Speeding up Unreal Editor launch by not spawning unused tooltips
#2This reminded me, I saw tooltips being a large chunk when I profiled my react app. I should go and check that.
Similarly, adding a modal like this
{isOpen && }
instead of
Seems to make the app smoother the more models we had. Rendering the UI (not downloading the code, this is still part of the bundle) only when you need it seems to be a low hanging fruit for optimizing performance.
Re: Speeding up Unreal Editor launch by not spawning unused tooltips
#3This reminded me, I saw tooltips being a large chunk when I profiled my react app. I should go and check that. Similarly, adding a modal like this {isOpen && } instead of Seems to make the app smoother the more models we had. Rendering the UI (not downloading the code, this is still part of the bundle) only when you need it seems to be a low hanging fruit for optimizing performance.
In the Blazor space we use factories/managers to spawn new instances of a modal/tooltip instead of having something idle waiting for activation.
The tradeoff is for more complicated components, first renders can be slower.
Re: Speeding up Unreal Editor launch by not spawning unused tooltips
#4This reminded me, I saw tooltips being a large chunk when I profiled my react app. I should go and check that. Similarly, adding a modal like this {isOpen && } instead of Seems to make the app smoother the more models we had. Rendering the UI (not downloading the code, this is still part of the bundle) only when you need it seems to be a low hanging fruit for optimizing performance.
I remember solving this problem before. These are both global components, so you create a single global instance and control them with a global context or function.
You basically have a global part of the component and a local part. The global part is what actually gets rendered when necessary and manages current state, the local part defines what content will be rendered inside the global part for a particular trigger and interacts with the global part when a trigger condition happens (eg hover timeout for a tooltip).
Re: Speeding up Unreal Editor launch by not spawning unused tooltips
#5Any time a library in your code goes from being used by a couple people to used by everyone, you have to periodically audit it from then on.
A set of libraries on our code had hit 20% of response time through years of accretion. A couple months to cut that in half, no architectural or cache changes. Just about the largest and definitely the most cost effective initiative we completed on that team.
Looking at flame charts is only step one. You also need to look at invocation counts, for things that seem to be getting called far more often than they should be. Profiling tools frequently (dare I say consistently) misattribute costs of functions due to pressures on the CPU subsystems. And most of the times I’ve found optimizations that were substantially larger improvements than expected, it’s been from cumulative call count, not run time.
Re: Speeding up Unreal Editor launch by not spawning unused tooltips
#6Any time a library in your code goes from being used by a couple people to used by everyone, you have to periodically audit it from then on. A set of libraries on our code had hit 20% of response time through years of accretion. A couple months to cut that in half, no architectural or cache changes. Just about the largest and definitely the most cost effective initiative we completed on that team. Looking at flame ch…
[deleted]
Re: Speeding up Unreal Editor launch by not spawning unused tooltips
#7This is one scenario where IMGUI approaches have a small win, even if it's by accident - since GUI elements are constructed on demand in immediate mode, invisible/unused elements won't have tooltip setup run, and the tooltip setup code will probably only run for the control that's showing a tooltip.
(Depending on your IMGUI API you might be setting tooltip text in advance as a constant on every visible control, but that's probably a lot fewer than 38000 controls, I'd hope.)
It's interesting that every control previously had its own dedicated tooltip component, instead of having all controls share a single system wide tooltip. I'm curious why they designed it that way.
Re: Speeding up Unreal Editor launch by not spawning unused tooltips
#8Kinda annoying that the article doesn't really answer the core question, which is how much time was saved in the start up time. It does give a 0.05ms per tooltip figure, so I guess multiplied by 38000 gives ~2s saved, which is not too bad.
Re: Speeding up Unreal Editor launch by not spawning unused tooltips
#9Don't have access to read the code, but I think ideally there should be only one instance created at startup, right?
Re: Speeding up Unreal Editor launch by not spawning unused tooltips
#10Kinda annoying that the article doesn't really answer the core question, which is how much time was saved in the start up time. It does give a 0.05ms per tooltip figure, so I guess multiplied by 38000 gives ~2s saved, which is not too bad.
"Together, these two problems can result in the editor spending an extremely long time just creating unused tooltips. In a debug build of the engine, creating all of these tooltips resulted in 2-5 seconds of startup time. In comparison development builds were faster, taking just under a second."