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.