LF Utility/Tool/Addon To Monitor Addon Resource Usage

[BigMons]

I apologize in advance for the length of this. Also, I'm not trying to pick on SnowmanDK or say bad things about Destinations. I've used the addon since I first started playing ESO and wouldn't play without it. I'm sure most if not all authors have made a minor mistake in their addon at some point.
-------
I use the addon Destinations. A bug was inadvertently introduced, or perhaps an oversight was made in coding, that caused pretty severe frame lag and freezing a couple of days ago. The issue was quickly fixed by the author. This question isn't really specifically about Destinations, but the Destinations bug that was causing the frame lag got me to thinking about it. Is there a tool or addon that can let an addon user see how much resources a particular addon is using or would help us to somehow find this particular type of issue in the future? I was just fortunate that I had only updated one addon recently, so it was easy to narrow down. If it was a new install with all of my addons, I could have wasted HOURS narrowing it down.

I have one addon called RAETIA Infohub (outdated and no longer supported unfortunately, but still working) that includes a module that supposedly reports current lua memory usage. I say supposedly because I have no idea if it works correctly or not, but it 'seems' to work. It does not give any details though regarding how much memory is being used by individual addons. I had a very similar addon in WoW that also included a similar module. Hovering over it would drop down more info about individual addons and would also offer the ability to do "garbage collection", which I assume just meant "free up lua memory", but idk.

I think it would be really handy from a troubleshooting perspective to be able to see memory/CPU/resource usage of individual addons to help figure out which addons are causing performance issues. It could help narrow down and figure out if there is a "bad", poorly written, or outdated addon that is causing issues. Maybe a log could be written that would show incorrect functions or bad calls (whatever you would call the issue Destinations had). I'm not a programmer or coder, so my terminology is probably incorrect.

If this doesn't exist, would it be possible to create a tool/utility or addon, given the current API, that would help to troubleshoot addons so I can figure out which ones to disable or uninstall if they are causing performance issues? I do use some outdated addons that may be causing issues or will later on.

I think we should request more API changes from ZOS if this isn't possible right now. I was cursing ESO last night and even alt+F4'd out of it and was going to play something else. I thought it was server lag or my connection. I was thinking "F' this, no point in playing the game if it's performing so poorly". The game wasn't fun and I thought it was ESO's fault. ZOS could benefit from adding functions to help with this. I just got lucky and found a forum post with a similar complaint where someone replied that it sounded like a bad addon.

[coolmodi]

Afaik it isn't possible atm, I searched for a way to get some info about addon resource usage when making GroupDamage, but I couldn't find anything.

[Ayantir]

The only thing we could do is a realtime Memory usage for Lua VM. It includes core ESOUI core and addons.

There is already some addons displaying this usage without drawing a chart. Maybe raetia or wikkyds for most end user addons.

After for badly coded addons, yes, it's a reality, addons are generally .. very badly coded.

There are good ones, some others very good too, but a good majority lack of optimization or are just not really well coded. If an user got 19 addons very well coded and 1 poorly optimized, you can do whatever you want in the first 19, the hole will be present and huge.

(that's my feeling after seeing LOT of addons, and not only mines).

It's not a blame, if some of us are pro coders, lot of us are only "week-end coders". They know how to build a code, maybe warned on coding mechanics and general algorithmics, but Lua guru are rares.

Then, there is a difference of an addon which badly use memory and addon which may provoke computer to slow down (cpu usage).

If some addons are known to have a poor memory usage, some others are well known to stress a bit too much the cpu. in some cases, it can be a bad design, in other cases, it's a too much.

A because a wide part of core can be rewrited, some addons may slow down others addons.
Problem can also be elsewhere.

Some devs polish their work, some others not at all. Some others are retired, some others just don't have time or skill for.



One of the first thing I do when taking care of a new addon is a global audit of its quality of code, it can be long, very quick, intuitive, or just depressing, it's just a question of how many time we'll require to do the choice, and choose wisely depending of the answer.

And I also have some poorly coded addons in my list, because, for me I just don't have time for.

[merlight]

Originally Posted by BigMons I think it would be really handy from a troubleshooting perspective to be able to see memory/CPU/resource usage of individual addons to help figure out which addons are causing performance issues.

Individual memory usage is close to impossible. There's no way to tell whether a table was allocated by addon X or addon Y, or core addon ZO_Ingame. A data table inside some other table inside some control could even be allocated by ZO_Ingame, filled by addon X with 200MB of garbage, and later wiped by addon Y. I haven't investigated whether it's possible to add some kind of memory allocation origin tracking to Lua GC, but even if it is, it won't be free. Every single allocation in every single addon and ZOS code would pay the price for tracking.

As for CPU usage, since everything (after initial script execution) add-ons do happens in response to events, it's possible to hook event registration functions and measure how much time is spent there -- here's a proof of concept. But there's a catch -- and you probably guessed it -- it's not free. For short, well-written handlers, the added time-keeping stuff could actually kill a perfectly working add-on. So this method would need to have an easy way to only profile selected events/addons. Although it is possible to do this kind of opt-in time-keeping for near-zero cost at the C level where handlers are called, I doubt ZOS will dedicate any resources to implement that. The best you can hope for is add-ons (whose authors have the time and will to do it) actively timing their own handlers.