11 ms·
Speeding up Unreal Editor launch by not spawning unused tooltips
- adithyassekhar 1y agoThis 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 && <Modal isOpen={isOpen} onClose={onClose} />} instead of <Modal isOpen={isOpen} onClose={onClose} /> 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.
- pathartl 1y agoIn 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.
- trylist 1y agoI 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).
- high_priest 1y agoReact devs re-discovering DOM manipulation... SMH. This is, in general, the idea that is being solved by native interaction with the DOM. It stores the graphic, so it doesn't have to be re-instated every time. Gets hidden with "display:none" or something. When it needs to display something, just the content gets swapped and the object gets 'unhidden'. Good luck.
- jitl 1y agoThe post you’re replying to is saying they went FROM always having the component mounted (at least in the component tree if not in the DOM as display:hidden), TO only mounting the component when it needs to be open. They moved from the way you’re talking about, to creating the component/DOM nodes only when needed. Excessive nodes - hidden or not - cost memory. On midrange Android it’s scarce and even if you’re not pushing against overall device memory limit, the system is more likely to kill your tab in the background if you’ve got a lot going on.
- adithyassekhar 1y agoEspecially when you know the user won't be opening half of those. I did'nt use a global one because the modals themselves have some complex logic inside.
- deleted 1y ago[deleted]
- llbbdd 1y ago"Devs use React because they how to use the web platform, here's how to do it right" and then posts a vanilla solution that doesn't solve understand or solve the problem. Tale as old as time. Bonus points if covering the edge cases in the vanilla solution and making it work for a second component would involve a tiny homegrown reimplentation of most of React anyway.
- deleted 1y ago[deleted]
- aiiizzz 1y agoThat breaks the out transition.
- amatecha 1y agoSo, win-win? I want a modal to get out of the way as fast as possible, any fade/transition animations are keeping me from what I want to look at. :)
- chamomeal 1y agoThe designers don’t want to break the out transition, and the PM wants whatever the designer wants
- akie 1y agoUnless you set `isOpen` only when the transition has ended
- debugnik 1y agoIsn't isOpen = false what triggers the transition in the first place here?
- abdusco 1y agoEven when using view transitions? https://developer.mozilla.org/en-US/docs/Web/CSS/@starting-style https://developer.mozilla.org/en-US/docs/Web/CSS/@starting-s...
- csande17 1y agoThe "Transitioning elements on DOM addition and removal" example in that article uses a setTimeout() to wait an extra 1000 milliseconds before removing the element from the DOM. If you immediately remove the element from the DOM (like would usually happen if you do {isOpen && <Modal />} in React), it'll vanish immediately and won't have time to play the transition.
- btown 1y ago
- Cthulhu_ 1y agoAlternatively, how many modals can be open at any given time? And is it a floating element? May be an option to make it a global single instance thing then, set the content when needed. Allows for in/out transitions, too, as another commenter pointed out. See also "Portals" in React.
- adithyassekhar 1y agoThere is only one. Won't contexts cause rerenders through the tree? We already use portals. It's just each modal have complex logic inside them that they're their own component.
- hinkley 1y agoAny 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.
- deleted 1y ago[deleted]
- smittywerben 1y agoDare me to say costless leaky abstraction. Then I'll point to the thread next door using Chrome profilers to diagnose Chrome internals using Scratch. Then I'll finish saying that at least Unreal has that authentic '90s feel to it.
- kg 1y agoThis 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.
- krzat 1y agoHow does this compare to React-like approach (React, Flutter, SwiftUI)? It seems like those libraries do what IMGUI do, but more structured.
- socalgal2 1y agoImGUIs you do whatever you want with your state. You read your state and call UI functions. React requires knowing about your state because it wants to monitor all of it for changes to try to optimize not doing things if nothing changed. This ends up infecting every part of your code to do so. It's the number 1 frustration I have using React. I haven't used Flutter or SwiftUI so I don't know if they are analogus
- bob1029 1y agoUnity uses an IMGUI approach and it makes all the difference in the universe. Overriding an OnDrawGizmos method to quickly get at an editor viz of a new component is super efficient. There are some sharp edges like forgetting to set/reset colors, etc, but I much prefer these little annoyances for the convenience I get in return. AFAIK, UE relies on a retained mode GUI, but I never got far enough into that version of Narnia to experience it first hand.
- lentil_soup 1y agoNo idea why you're getting down voted but that was my thought as well. With immediate mode you don't have to construct any widgets or objects. You just render them via code every frame which gives you more freedom in how you tackle each UI element. You're not forced into one widget system across the entire application. For example, if you detect your tooltip code is slow you could memcpy all the strings in a block of memory and then have tooltips use an index to that memory, or have them load on demand from disk, or the cloud or space or whatever. The point being you can optimise the UI piecemeal. Immediate mode has its own challenges but I do find it interesting to at least see how the different approaches would tackle the problem
- ehsankia 1y agoKinda 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.
- charlie-83 1y ago"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."
- deleted 1y ago[deleted]
- 0xml 1y agoDon't have access to read the code, but I think ideally there should be only one instance created at startup, right?
- RossBencina 1y agoAt most one instance at start up. Asynchronous creation or lazy creation on first use are two other potential options. Speaking generally, not Unreal-specific.
- WhereIsTheTruth 1y agoI once made the mistake to buy some sound effects from Fab, I had to download the entire Unreal Engine and start it to create a project to then import the assets.. It took the whole afternoon It's no wonder UE5 games have the reputation of being poorly optimized, you need an insane machine only just to run the editor.. State of the art graphics pipeline, but webdev level of bloat when it comes to software.. I'd even argue electron is a smoother experience tan Unreal Engine Editor Insanity
- daemin 1y agoYet it is the engine dominating the industry and beloved by artists of all kinds. To get UE games that run well you either need your own engine team to optimise it or you drop all fancy new features.
- Ekaros 1y agoBeing around back in days when LCDs replaced the CRTs and learning importance of native resolutions. I feel like recent games have been saved too much by frame-generation and all sort of weird resolution hacks... Mostly by Nvidia and AMD. I am kinda sad we have reached point where native resolution is not the standard for high mid tier/low high tier GPUs. Surely games should run natively at non-4k resolution on my 700€+ GPU...
- daemin 1y agoGames haven't been running full native resolution for quite some time, maybe even the last decade, as they tend to render to a smaller buffer and then upscale to the desired resolution in order to achieve better frame rates. This doesn't even include frame generation which is trading off supposed higher frame rates for worse response times so the games can feel worse to play. By Games I mean modern AAA first or third person games. 2D and others will often run at full resolution all the time.
- cheschire 1y agoYou mean back in the day when 30 fps at 1024x768 was the norm? New monitors default to 60hz but folks looking to game are convinced by ads that the only reason they lost that last round was not because of the SBMM algorithm, but because the other player undoubtedly had a 240hz 4K monitor rendering the player coming around the corner a tick faster. Competitive gaming and Twitch are what pushed the current priorities, and the hardware makers were only too happy to oblige.
- Sharlin 1y agoHmm, so what exactly is stored in that gigabyte of tooltips? Even 100,000 tooltips per language should take maybe a few tens of megabytes of space. How many localizations does the editor have?
- lukan 1y agoIt is not the text data. It is that every tool tip gets made into an UI element. "Firstly, despite its name, the function doesn’t just set the text of a tooltip; it spawns a full tooltip widget, including sub-widgets to display and layout the text, as well as some helper objects. This is not ideal from a performance point of view. The other problem? Unreal does this for every tooltip in the entire editor, and there are a lot of tooltips in Unreal. In fact, up to version 5.6, the text for all the tooltips alone took up around 1 GB of storage space." But I assume the 1GB storage for all tooltips include boilerplate. I doubt it is 1 GB of raw text.
- Sharlin 1y agoYes, I meant the size on disk. I presume the serialization format isn't the most efficient possible. But I can't think of any particular boilerplate that you'd want to store in a file that's just supposed to store localization strings.
- cardanome 1y agoThat seems like a very wastefull way to implement tooltips. The user can ever only see one single tooltip. (Or maybe more if you have tooltips for tooltips but I don't think Unreal has that, point is, a limited number.) So initialize a single tooltip object. When the users mouses over an element with an tooltip, set the appropriate text, move the tooltip widget to the right position and show it. If the user moves away, hide it. Simple and takes nearly no memory. Seems like some people still suffer from 90s OOP brain rot.
- bob1029 1y agoFrom a purely technical perspective, UE is an absolute monster. It's not even remotely in the same league as Unity, Godot, etc. when it comes to iteration difficulty and tooling. I struggle with UE over others for any project that doesn't demand an HDRP equivalent and nanometric mesh resolution. Unity isn't exactly a walk in the park either but the iteration speed tends to be much higher if you aren't a AAA wizard with an entire army at your disposal. I've never once had a UE project on my machine that made me feel I was on a happy path. Godot and Unity are like cheating by comparison. ~Instant play mode and trivial debugging experience makes a huge difference for solo and small teams. Any experienced .NET developer can become productive on a Unity project in <1 day with reasonable mentorship. The best strategy I had for UE was to just use blueprints, but this is really bad at source control and code review time.
- cheschire 1y agoAnd blueprints take forever to wire up in my experience compared to just writing the C++ directly.
- diggan 1y agoNever worked in a larger game-dev team before, but I always saw the benefits of Blueprints to be mainly for the ones who don't know how to code. Setup the right abstractions and you can let the level designers add interactivity for example, rather than Blueprints mainly existing for speeding up the work of C++ devs.
- markus_zhang 1y agoI think UE requires the dev team to have a clear cut between the designers and programmers. Programmers code BP "components" and give them to designers to wire them up. The heavy lifting and complicated logic should live in C++ IMO. Otherwise it's going to be hell.
- smittywerben 1y agoNEW QUEST: "These New Gaming Requirements Are Unreal" OBJECTIVE: Any project that demands HDRP and Nanometric Mesh BONUS: Find the happy path
- thaumasiotes 1y agoThis was originally submitted with the title "Speeding up Unreal Editor launch by not spawning 38000 tooltips", a much closer match to the actual title of the post, "Speeding up the Unreal Editor launch by ... not spawning 38000 tooltips". Why has it been changed? The number of tooltips improves the title and is accurate to the post.
- Yiannis128 1y agoThey really need to rewrite the whole editor, or at least strip down unused systems... The whole thing being that big is inexcusable...
- Stevvo 1y agoI recently decided the fastest way to work with Unreal is to throw it out and go with something else. It's like 10 fucking minutes to compile an empty project. I like Godot primarily because of GDScript; you are not compiling anything so iteration time is greatly reduced. Unigine is also worth a mention. It has all the modern features you could want like double precision, global illumination etc but without the bloat and complexity. It's easy to use as much or as little of the engine as you need; in every project you write the main() function. Similar license options to Unity/Unreal.