Go to Page... |
|
Thread Tools | Display Modes |
08/31/24, 12:24 PM | #1 | |
Join Date: Jun 2019
Posts: 30
|
Deferred initialization to speed up loading screen?
Hi All,
I'm curious about a trend I've noticed in some addon changelogs which mention implementing "deferred initialization" for slightly faster loading screens. In my own experience, addons can have a huge impact on load times:
I'd appreciate any insights from addon developers or experienced users. Thanks in advance! |
|
![]() |
08/31/24, 03:44 PM | #2 |
Let's start with 3. There's a lot of possible reasons why not, but I have an add on that's a great candidate, and it's so nice that you're offering to do the work to convert it! There's a github for it and I take PR requests and...
So, yeah, that's reason #1 why not. It takes time and effort to convert an addon to defer the initialization. Some other reasons: Major changes to add-ons also run the risk of introducing major bugs The load gains are vastly disproportionate to the effort required. If an addon only requires 1 second to load why bother? The addon is so simple that there's simply no point The addon has nothing that can be deferred or is deferred by nature (for example, an addon that only does stuff in trials is essentially deferred anyway) No one is maintaining the addon The addon might already use deferred initialization You always need the addon anyway So as you can see, there's a lot of reasons why an addon is very likely to not be converted to use deferred initialization. Addons that are good candidates for deferred initialization are ones that need to do a lot of computation or create a lot of UI elements that may or may not be required by the user. For question 2, it's going to be vastly more noticeable on slower systems, because if your game loads in 20 seconds, it's not going to be much different if it loads in half the time. Also, some stuff is fixed time to load (e.g. wait for server information on items and skills cannot be sped up) |
|
![]() |
08/31/24, 05:17 PM | #3 |
Defered init always could make sense if you want to move operations that take time to the moment it is first needed.
As most addons do need their data directly they cannot use a deferred init. Some could be charged, for exempt the ones that provide an seperate UI. But that depends on many things as Dolgubon explained above. In the most cases the performance gain will be minimal an time invested a lot. So new addons created might benefit from that, but changing existing ones.. |
|
![]() |
08/31/24, 05:30 PM | #4 | |
Join Date: Jun 2019
Posts: 30
|
Super insightful, I appreciate your responses! I'm not really a coder (at least not without AI), but if I do make something in the future I plan to utilize this if applicable!
|
|
![]() |
08/31/24, 05:56 PM | #5 |
To add to Dolgubon's already correct answers:
Is deferred initialization feasible for most addons? Yes, you can defer the initialization code for any addon if you wish so. The bigger question is if it makes sense to do that. In case you don't know, the Lua VM is single threaded, meaning it can only do one thing at a time. It's also tied into the game loop, so anything addons do will directly impact your frames per second. Let's say you expect your game to run at 60 fps, that would mean the game has 16.6ms of time to do all calculations. A part of that time is taken up by rendering, the ingame UI and other internal processing, so addons only have around 5ms or so per frame to do all their processing before they start to impact your frame rate. During the initial loading screen, the ingame UI and all active addons load their files, their save data and initialize their state. This is done without regard for the frame rate at full throttle, which means if you were to simply not show that loading screen you'd notice that the game currently runs at close to 0 fps. Now if an addon that takes 5 second to initialize its state were to defer that initialization, it would simply freeze your client for those five second at a later time, after the loading screen is gone. That's obviously not good. So instead it would now need to use LibAsync (or some similar mechanism) to spread out the initialization over multiple frames so you do not notice that something is happening in the background. Assuming it's the only addon and there are 5ms each frame for addons to safely do calculations, the 5 seconds of initialization would suddenly have to be spread to 1000 frames. At 60fps that would mean the deferred initialization would take around 16 seconds. Start using other addons, or a slower CPU and it gets even worse. How significant is the performance improvement from deferred initialization? Is it noticeable only on slower systems, or does it benefit everyone? As described above, there are no implicit performance improvements to be had, because the addon would still have to do all the same calculations which would take the same duration overall, but depending on circumstances may have to be spread out to not affect the fps in a negative way. The most useful case for applying deferred initialization is for things that are not needed immediately. Like an addon that adds a few controls to a menu that is rarely opened. If 50 of your 100 addons start doing that, it may shave off a few seconds from the initial loading screen, without having a noticeable impact on fps, since you simply can't open all menus at the same time. Why don't more addon developers implement this technique? Are there specific reasons/limitations that prevent its widespread adoption? Because most addon developers are hobbyists and sometimes even absolute beginners at programming, who simply don't know how or why. Authors often already struggle to understand how regular loading of addons works, where code is processed file by file and line by line. Throw in deferred initialization where things are suddenly loaded out of order and you'll get to a level of complexity that you simply cannot expect a novice to know or care about. |
|
![]() |
08/31/24, 07:13 PM | #6 |
|
A good candidate for deferred initialization would be UI controls used in non-HUD scenes.
For example, the quick slot settings screen or the crown store, because those are not used until user interaction. For add-ons, the popular LibAddonMenu originally used the deferred initialization technique. So, in essence, there is little room for add-ons to improve. |
![]() |
09/03/24, 09:02 AM | #7 |
One other thing I didn't see mentioned here but is a big indicator for me that it's a good candidate for deferral: the screen/add-on/whatever has a lot of controls or caches a lot of memory. Maybe it doesn't take a long TIME to load, but it holds on to a lot of data. If this is something that is niche and maybe won't be needed every time the game is played, you could defer that and only eat those costs when necessary (i.e.: the player actually goes to engage with it). This is a admittedly a bigger problem on console than it is on PC, unless the user has a low end machine spec. But it is still a good habit to at least be thinking about it. Note that most gamepad screens have been some form of deferred init since their inception, because again, this is a much bigger issue on console, where memory is a premium.
Also note that deferred init only works with something that has a scene/fragment/scene group. It is not supported for managers or libraries, at least not out of the box. Those kind of things are deferred through manually writing of "lazy loading" of your objects as the dev sees fit/appropriate. But as Sirin said: it's not generally a good idea to defer a long operation, because hiding a long operation in the load screen is better than having the game hitch when a menu opens for the first time. Another way to ensure you don't do more work than necessary is by implementing refresh groups and making sure things like lists aren't populated prior to the screen showing. An event could tell the system that the list needs to be refreshed, but the refresh shouldn't happen until the next time the scene shows. If every hidden scene was responding to every event by rebuilding every control all the time, the framerate would take a hit. So deferred init is just one tool in a box of tools to help ensure you're not wasting time doing things the player doesn't need done right now. When I went on my recent deferred init spree, I cut the number of controls created at load time by several thousand, more than a 10% reduction. Last edited by ZOS_DanBatson : 09/03/24 at 09:05 AM. |
|
![]() |
ESOUI » Developer Discussions » General Authoring Discussion » Deferred initialization to speed up loading screen? |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
![]() |
![]() |
![]() |
|
|