First post here so sorry in advance if it is in the wrong forums... Let me know & I'll move it, or if you are happy to do so, move it for me ;)
Down to business...
Upon using an ever-growing collection of addons, the load-time for my ui has become increasingly long, I recently came across an out-dated addon by the name of Zoom which halts the garbage collection feature of the ui until all addons have loaded, which makes for a large decrease in load-time for the ui unfortunately as it is so out-dated it doesn't pick up more than 1/2 of my addons... I was wondering if the author of the addon is still around to maybe work on it or if there was another author willing to take it up, pending of course, on the original author's approval...
Alternatevily if an author could throw some pointers my way in updating the addon itself I would be happy to venture into the fray of addon management.
ty for the tip... Upon looking @ a couple of addons with the tag for addonloader & some without, I'm thinking I will just hack the ones without the tag to set them as delayed upon load, will take a little while to do though should do though the means should justify the end result.
ty again for the reply.
EDIT:
Quick question here while I play around with the toc files... Will setting every addon to have a delayed load-time other than the addon 'Zoom', which I will set to Always, is there any problem that I don't have hindsight of?
I guess in other words, which method does addonloader use to load addons?
ty for the tip... Upon looking @ a couple of addons with the tag for addonloader & some without, I'm thinking I will just hack the ones without the tag to set them as delayed upon load, will take a little while to do though should do though the means should justify the end result.
ty again for the reply.
EDIT:
Quick question here while I play around with the toc files... Will setting every addon to have a delayed load-time other than the addon 'Zoom', which I will set to Always, is there any problem that I don't have hindsight of?
I guess in other words, which method does addonloader use to load addons?
What I would do is this
In the ToC, of the other addons in the line for ## OptionalDeps:
Add Addonloader, !!!Zoom!!!
In Addonloader add !!!Zoom!!!
With WoW addons, adding the ## OptionalDeps:
will load that addon prior to other addons, allowing them to take use of their functions when loaded.
As a side note, I believe WoW uses something similar for loading, as I run 324 Addons (Disembedded), Meaning the changes to LoD has changed since Zooms release.
Garbage collected: 4.95 kb, 5 attempts were made to collect garbage, loading took 10.34 seconds.
vs Loading took 10.41 seconds w/out Zoom
Cartographer_QuestInfo, PitBull 4 being the 2 largest starting up at Player_Login
What I would do is this
In the ToC, of the other addons in the line for ## OptionalDeps:
Add Addonloader, !!!Zoom!!!
In Addonloader add !!!Zoom!!!
With WoW addons, adding the ## OptionalDeps:
will load that addon prior to other addons, allowing them to take use of their functions when loaded.
Aye, that was my intention once I started hacking the files...
I'm planning on making addonloader dependent on the zoom addon with all the other addons dependent on addonloader, cuts down on amount of copy/pasting plus means I don't have to use clipboard or a new notepad file to collate what I want to copy/paste :)
If you make them all delayed, Zoom will have no effect. Look at the code, it's only 24 lines. All it does is hook the garbage collect function so that it doesn't do anything, then, when the PLAYER_ENTERING_WORLD event is received, it unhooks the garbage collect function so it works again, and Zoom disables itself. So if you delay your addons to load after you have "entered the world" Zoom will have no effect on them.
A better solution, in my opinion, is to search through your addon code and simply remove all the calls to collectgarbage. Lua will collect garbage when it needs to.
mmm, I pretty much changed the dependency of all addons to to load 'addonloader' first, changed addonloader to load 'zoom' first so it holds the garbage collection, it does the job though it still doesn't grab all of the garbage collection calls as the addons are still loading once the 'player has entered world' tag has fired...
Would be better to just alter that tag in 'zoom' now since I have it firing as the first addon to be loaded.
Anybody know of an event that would be good to have 'zoom' look for before it does an end call to disable itself and restart the garbage collection of the ui feature?
Going through all the addons to find the hooks for garbage collection just to remove those lines seems to be a bit of an overkill when one addond can do the job itself now that it is more or less sequential in loading ;p
So in the end what I ended up doing was tagging all the addons that don't have load dependency to be dependent on addonloader, then tagged addonloader to be dependent on the addon zoom, then changed the event call for zoom from player_enter_world to CHAT_MSG_CHANNEL_NOTICE, which is the event that is called before you see 'Joined channel 1.general, etc.' when you load in... Did that to escape any addons still being loaded/memory active after the player_entered_world event... Seems to work fine, was around 35-40 seconds loading down to 10-15 on average.
Wether or not it actually does work, or was just good luck on resources not being used by background applications at the time... It seems to be doing the job atm.
Make a list of addons that call collectgarbage() and report the issue to the author. There is no reason for any addon to call this function without user input.
So in the end what I ended up doing was tagging all the addons that don't have load dependency to be dependent on addonloader, then tagged addonloader to be dependent on the addon zoom, then changed the event call for zoom from player_enter_world to CHAT_MSG_CHANNEL_NOTICE, which is the event that is called before you see 'Joined channel 1.general, etc.' when you load in... Did that to escape any addons still being loaded/memory active after the player_entered_world event... Seems to work fine, was around 35-40 seconds loading down to 10-15 on average.
Wether or not it actually does work, or was just good luck on resources not being used by background applications at the time... It seems to be doing the job atm.
Interesting how many collectgarbage calls are being made? NASTY SIDE EFFECT with CHAT_MSG_CHANNEL_NOTICE
It does something with ReloadUI, assume constantly spams collectgarbage when you receive a message
Since it never added the message, as well when Querying memory usage of the addons, all of them returned 0
Make a list of addons that call collectgarbage() and report the issue to the author. There is no reason for any addon to call this function without user input.
It depends really, for every object created and disposed in WoW there is some residual memory left over. Alot of authors feel the memory left over is worth the call to collectgarbage.
Though I agree, it should only be called for once the player is in the game.
Not after setting variables up during addon load process.
Curious to see what loading Zoom in libstub dependcies will do.
It depends really, for every object created and disposed in WoW there is some residual memory left over. Alot of authors feel the memory left over is worth the call to collectgarbage.
In my opinion this is completely bogus. Calling collectgarbage deprives the interpreter engine from sensibly collecting the garbage incrementally and slowly in a low priority thread (i.e. it never disturbs the thread that runs the addons), and only forcible running a blocking garbage collect if it really needs to (which does disturb the thread running the addons). The memory released during garbage collection is returned to the pool used by the interpreter only, so you achieve exactly nothing by doing it, except that you always keep more memory idle than you have to, and you expend more high priority cycles collecting garbage than you have to.
Addons that collect garbage usually does so because they pretend to think that they know when it is opportune to do so, and they think that if they do it at this oppertune time it will not happen later at a bad time. This way of thought is flawed, because a single addon does not know when it is a good time to spend cycles doing this, and the incremental garbage collection used by Lua is never noticable (as it was in the early days of wow, where the garbage collection was invoked as a blocking call when it ran out of addon memory).
Not to mention memory isn't relevant and if you are creating enough garbage every time on login that you "need" to force it's collection, you are doing something you shouldn't be.
It depends really, for every object created and disposed in WoW there is some residual memory left over. Alot of authors feel the memory left over is worth the call to collectgarbage.
That's incorrect. And addon can not and should not call collectgarbage() because it possibly created a lot of memory that needs collection. There is no addon that is by himself important enough to force the full lua heap to be traversed just to clean up its mess.
Let the system handle itself. It took some time, but it's correctly tuned now and works. Even if it didn't, then let the user get THE addon that will call collectgarbage. Don't force the user to have yet another addon just to replace every calls to collectgarbage() to nops.
Well, Zoom exists, and in fact i use it, but i've modified it slightly so it never unhooks collectgarbage, effectively cutting those pesky addons off from using it. I think that is easier than replacing the calls in all the addons.
I got the following addons that think they know when to collect garbage:
I agree that most addon's shouldn't call collectgarbage("collect"), but Recount's use is legit and in fact needed unless I want to get permaspammed by users with (misunderstood) bug reports about it's user-initiated delete data feature.
Recount does not collectgarbage during startup or on data that is indeed well-cared for with incremental GC.
That's incorrect. And addon can not and should not call collectgarbage() because it possibly created a lot of memory that needs collection. There is no addon that is by himself important enough to force the full lua heap to be traversed just to clean up its mess.
Let the system handle itself. It took some time, but it's correctly tuned now and works. Even if it didn't, then let the user get THE addon that will call collectgarbage. Don't force the user to have yet another addon just to replace every calls to collectgarbage() to nops.
This is absurd.
I originally stated that I AGREED and collectgarbage should not be called, at least until the player is in the world. A lot of authors feel it's a good idea to call for collectgarbage when they feel fit, having several calls in the load process..
I do not agree with calling collectgarbage every 5mins just because, or everytime I open my bags. Nor do I condone it.
The problem is that it's there, and used poorly, thus my statement is not incorrect...
Now from a different perspective, not everyone has the latest and greatest system out there. I personally know of people who play with 512MB SDRAM, onboard video, sound, etc. From that stand point the additional data stored by an addon, to lets say set defaults. Once the addon is loaded, that data is no-longer needed, or called for, but its so little data don't bother collecting garbage.
Having several addons call collectgarbage at this point is idiotic. Considering every image, model, sound, and addon data is stored in memory, if the same user above running recap in matrix mode, stored 45mins of clearing trash in 25 man Nax. Their PC is going to run slow. I'd expect when they press "Clear Data" That the memory is also freed, not just set all the variables to nil.
The same goes for using XPerl, while I'm in a raid, let it run, I leave a raid, why keep the data in memory?
Yes it eats a lot of cycles, and effectively locks the WoW environment while this occurs, in some cases.. a good practice, other's moronic.
Sadly it's still an issue and is in our addons.
Honestly I wish there were a dispose for the local scope of an addon.
That way only the addon's scope is disposed of when needed.
Doing myArray = {} is not a dispose as the array's data "size" is still stored in memory, unless LUA or any other scripting language has changed this.
Honestly I wish there were a dispose for the local scope of an addon.
That way only the addon's scope is disposed of when needed.
Doing myArray = {} is not a dispose as the array's data "size" is still stored in memory, unless LUA or any other scripting language has changed this.
Curly braces create new tables. Always. "{.....}" is not a scope delimiter like in C++.
I agree that most addon's shouldn't call collectgarbage("collect"), but Recount's use is legit and in fact needed unless I want to get permaspammed by users with (misunderstood) bug reports about it's user-initiated delete data feature.
You means that when a user press "delete that data" on Recount, then you end up calling collectgarbage() ? That's indeed fine, User action initiated calls are fine wherever they are. I was ranting about automated calls to collectgarbage(). That should have been clearer in my second post.
Now from a different perspective, not everyone has the latest and greatest system out there. I personally know of people who play with 512MB SDRAM, onboard video, sound, etc. From that stand point the additional data stored by an addon, to lets say set defaults. Once the addon is loaded, that data is no-longer needed, or called for, but its so little data don't bother collecting garbage.
Most addon I know of do not bother about this and will keep around the code and data use for initialisation, even if it's never gonna be used by the addon. One of the worst effect of using a heavy "upvalue" based code is that keeping track (as a developer) of what's gonna get reclaimed is difficult.
The same goes for using XPerl, while I'm in a raid, let it run, I leave a raid, why keep the data in memory?
You should understand that garbage memory will be reclaimed by the system even if no addon ever calls collectgarbage() ever. This process is done in small steps, while executing other instructions. It's called the "incremental garbage collection cycle".
You should understand that garbage memory will be reclaimed by the system even if no addon ever calls collectgarbage() ever. This process is done in small steps, while executing other instructions. It's called the "incremental garbage collection cycle".
Yep, I know and like what they've done with it so far, compared to previous versions of WoW.
Basically we've been trying to find a way to stop the collectgarbage calls during the addon load process.
For me disembedding, and adding Zoom, I've brought 314 Addons load time to 10 seconds in Iron Forge.
Well, Zoom exists, and in fact i use it, but i've modified it slightly so it never unhooks collectgarbage, effectively cutting those pesky addons off from using it. I think that is easier than replacing the calls in all the addons.
I got the following addons that think they know when to collect garbage:
Same ones here, though I use BigWigs vs DBM, which is LoadOnDemand for function loadZone(zone), in which when I enter an instance it calls for it.
Lightheaded is very heavy, MobMap is another, when their databases are loaded.
Testing something....
Not working, even if I hook the call to itself to prevent collectgarbage from ever running (even in an infinite loop) it still calls and collects it.
Down to business...
Upon using an ever-growing collection of addons, the load-time for my ui has become increasingly long, I recently came across an out-dated addon by the name of Zoom which halts the garbage collection feature of the ui until all addons have loaded, which makes for a large decrease in load-time for the ui unfortunately as it is so out-dated it doesn't pick up more than 1/2 of my addons... I was wondering if the author of the addon is still around to maybe work on it or if there was another author willing to take it up, pending of course, on the original author's approval...
Alternatevily if an author could throw some pointers my way in updating the addon itself I would be happy to venture into the fray of addon management.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumty for the tip... Upon looking @ a couple of addons with the tag for addonloader & some without, I'm thinking I will just hack the ones without the tag to set them as delayed upon load, will take a little while to do though should do though the means should justify the end result.
ty again for the reply.
EDIT:
Quick question here while I play around with the toc files... Will setting every addon to have a delayed load-time other than the addon 'Zoom', which I will set to Always, is there any problem that I don't have hindsight of?
I guess in other words, which method does addonloader use to load addons?
What I would do is this
In the ToC, of the other addons in the line for ## OptionalDeps:
Add Addonloader, !!!Zoom!!!
In Addonloader add !!!Zoom!!!
With WoW addons, adding the ## OptionalDeps:
will load that addon prior to other addons, allowing them to take use of their functions when loaded.
As a side note, I believe WoW uses something similar for loading, as I run 324 Addons (Disembedded), Meaning the changes to LoD has changed since Zooms release.
Garbage collected: 4.95 kb, 5 attempts were made to collect garbage, loading took 10.34 seconds.
vs Loading took 10.41 seconds w/out Zoom
Cartographer_QuestInfo, PitBull 4 being the 2 largest starting up at Player_Login
Aye, that was my intention once I started hacking the files...
I'm planning on making addonloader dependent on the zoom addon with all the other addons dependent on addonloader, cuts down on amount of copy/pasting plus means I don't have to use clipboard or a new notepad file to collate what I want to copy/paste :)
A better solution, in my opinion, is to search through your addon code and simply remove all the calls to collectgarbage. Lua will collect garbage when it needs to.
Would be better to just alter that tag in 'zoom' now since I have it firing as the first addon to be loaded.
Anybody know of an event that would be good to have 'zoom' look for before it does an end call to disable itself and restart the garbage collection of the ui feature?
Going through all the addons to find the hooks for garbage collection just to remove those lines seems to be a bit of an overkill when one addond can do the job itself now that it is more or less sequential in loading ;p
Wether or not it actually does work, or was just good luck on resources not being used by background applications at the time... It seems to be doing the job atm.
Interesting how many collectgarbage calls are being made?
NASTY SIDE EFFECT with CHAT_MSG_CHANNEL_NOTICE
It does something with ReloadUI, assume constantly spams collectgarbage when you receive a message
Since it never added the message, as well when Querying memory usage of the addons, all of them returned 0
It depends really, for every object created and disposed in WoW there is some residual memory left over. Alot of authors feel the memory left over is worth the call to collectgarbage.
Though I agree, it should only be called for once the player is in the game.
Not after setting variables up during addon load process.
Curious to see what loading Zoom in libstub dependcies will do.
In my opinion this is completely bogus. Calling collectgarbage deprives the interpreter engine from sensibly collecting the garbage incrementally and slowly in a low priority thread (i.e. it never disturbs the thread that runs the addons), and only forcible running a blocking garbage collect if it really needs to (which does disturb the thread running the addons). The memory released during garbage collection is returned to the pool used by the interpreter only, so you achieve exactly nothing by doing it, except that you always keep more memory idle than you have to, and you expend more high priority cycles collecting garbage than you have to.
Addons that collect garbage usually does so because they pretend to think that they know when it is opportune to do so, and they think that if they do it at this oppertune time it will not happen later at a bad time. This way of thought is flawed, because a single addon does not know when it is a good time to spend cycles doing this, and the incremental garbage collection used by Lua is never noticable (as it was in the early days of wow, where the garbage collection was invoked as a blocking call when it ran out of addon memory).
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat's incorrect. And addon can not and should not call collectgarbage() because it possibly created a lot of memory that needs collection. There is no addon that is by himself important enough to force the full lua heap to be traversed just to clean up its mess.
Let the system handle itself. It took some time, but it's correctly tuned now and works. Even if it didn't, then let the user get THE addon that will call collectgarbage. Don't force the user to have yet another addon just to replace every calls to collectgarbage() to nops.
This is absurd.
I got the following addons that think they know when to collect garbage:
DBM
Lightheaded
MSBT
LibDogTag-3.0
LibDogTag-Unit-3.0
Prat-3.0
Recount
All written by quite experienced authors...
Recount does not collectgarbage during startup or on data that is indeed well-cared for with incremental GC.
I do not agree with calling collectgarbage every 5mins just because, or everytime I open my bags. Nor do I condone it.
The problem is that it's there, and used poorly, thus my statement is not incorrect...
Now from a different perspective, not everyone has the latest and greatest system out there. I personally know of people who play with 512MB SDRAM, onboard video, sound, etc. From that stand point the additional data stored by an addon, to lets say set defaults. Once the addon is loaded, that data is no-longer needed, or called for, but its so little data don't bother collecting garbage.
Having several addons call collectgarbage at this point is idiotic. Considering every image, model, sound, and addon data is stored in memory, if the same user above running recap in matrix mode, stored 45mins of clearing trash in 25 man Nax. Their PC is going to run slow. I'd expect when they press "Clear Data" That the memory is also freed, not just set all the variables to nil.
The same goes for using XPerl, while I'm in a raid, let it run, I leave a raid, why keep the data in memory?
Yes it eats a lot of cycles, and effectively locks the WoW environment while this occurs, in some cases.. a good practice, other's moronic.
Sadly it's still an issue and is in our addons.
Honestly I wish there were a dispose for the local scope of an addon.
That way only the addon's scope is disposed of when needed.
Doing myArray = {} is not a dispose as the array's data "size" is still stored in memory, unless LUA or any other scripting language has changed this.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCurly braces create new tables. Always. "{.....}" is not a scope delimiter like in C++.
Meant in terms of already formed tables
You means that when a user press "delete that data" on Recount, then you end up calling collectgarbage() ? That's indeed fine, User action initiated calls are fine wherever they are. I was ranting about automated calls to collectgarbage(). That should have been clearer in my second post.
Most addon I know of do not bother about this and will keep around the code and data use for initialisation, even if it's never gonna be used by the addon. One of the worst effect of using a heavy "upvalue" based code is that keeping track (as a developer) of what's gonna get reclaimed is difficult.
You should understand that garbage memory will be reclaimed by the system even if no addon ever calls collectgarbage() ever. This process is done in small steps, while executing other instructions. It's called the "incremental garbage collection cycle".
Basically we've been trying to find a way to stop the collectgarbage calls during the addon load process.
For me disembedding, and adding Zoom, I've brought 314 Addons load time to 10 seconds in Iron Forge.
Same ones here, though I use BigWigs vs DBM, which is LoadOnDemand for function loadZone(zone), in which when I enter an instance it calls for it.
Lightheaded is very heavy, MobMap is another, when their databases are loaded.
Testing something....
Not working, even if I hook the call to itself to prevent collectgarbage from ever running (even in an infinite loop) it still calls and collects it.