Go to Page... |
Thread Tools | Display Modes |
Yesterday, 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! |
|
![]() |
Yesterday, 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) |
|
![]() |
Yesterday, 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.. |
|
![]() |
Yesterday, 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!
|
|
![]() |
Yesterday, 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. |
|
![]() |
Yesterday, 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. |
![]() |
ESOUI » Developer Discussions » General Authoring Discussion » Deferred initialization to speed up loading screen? |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
![]() |
![]() |
![]() |
|
|