nUI5 CPU usage
 

While working on another addon, I wanted to measure the amount of processing time it was using, so I installed the "Broker_CPU Memory" addon and ran about 15 minutes of LFR (essentially 15 minutes of combat). I reset the CPU counters when I entered the instance, to clear out login/initialization activity.

This was the first time I had ever profiled addon CPU usage. The results for my own addon were fine, but nUI's CPU usage surprised me. For the period I sampled, which was again about 15 minutes, nUI used 2 minutes of CPU time, which was 5 times as much as Vuhdo (my character is a healer, so Vuhdo was showing all 25 members and being used continuously), and 10 times as much as Recount. Overall, nUI used twice as much CPU time as my other 40 or so addons combined.

Admittedly, nUI does a lot more than any other single addon, and takes over a number of functions of the Blizzard UI. Of my other addons, Vuhdo is probably the best comparison, since it is also maintaining 26raid frames, monitoring buffs/debuffs on all raid members, etc. In addition, nUI is showing a HUD and managing action buttons. Vuhdo is also parsing the combat log, I believe. So I would naively expect nUI to be perhaps twice as CPU-intensive as Vuhdo. But five times is considerably more than I would have estimated.

So I did a second test, this time standing idle in the Shrine for 15 minutes. I was solo (so only one unit frame), and I used no abilities, so no cooldowns/action button activity, and my health/mana didn't change, so no HUD activity. Surprisingly, while I was totally idle for 15 minutes, nUI used over 2/3's of the CPU time it used in the same amount of LFR combat: about 85 seconds while idle, compared to 120 while in combat almost continuously. For comparison, idle Vuhdo used less than 3% of the CPU time it used in combat (24 seconds in combat, 0.67 seconds out of combat).

I don't care so much about CPU usage while standing around, but wasting all that time while idle MAY indicate that a lot of time is also being wasted while in combat. It also seems possible that the wasted time may be localized to one or two things done in the OnUpdate handler. If so, perhaps some of the inefficiency could be eliminated without massive changes or waiting for nUI6.

Update: Having played around for a while, what I've found is:

60% of the CPU time when idle (solo) is spent in calls to the nUI_Button:OnUpdate routines
30% of the CPU time when idle (solo) is spent in calls to the nUI_UnitAura:OnUpdate routine

the other 10% is divided between everything else.

You've hit on what was one of the biggest flaws in nUI5 and the primary driving reason for (a) me doing a complete rewrite a la nUI6, and, (b) why nUI6 is taking so very long for me to rewrite. It's the "working around the work load" problem that's I'm being so very OCD about.

nUI5 was my first ever WoW mod -- a rather ambitious undertaking for a first time modder -- and there was much I didn't know when I started. And much that changed in the WoW API over the years for which I had to code around and hack.

It's is my deepest hope that nUI6 will not suffer from the same issues you're seeing here.

The problem is that while it would appear that the issue is one or two places, the truth is that is it in those couple of places because of the larger architecture of the entire design. The architecture forced all of the work, and too much work, into a narrow corridor and front-loaded the effort into the combat stream. I'm trying, instead, to build a more event driven solution that uses more of the WoW API's C code and less Lua code.

Out of curiosity, which profiler did you use to measure usage by function?

FWIW: nUI5 is consuming roughly 8.5% of the CPU standing idle. nUI6 is consuming around 1.2% idle... but it still has issues I haven't nailed down yet.

Heh.

I used the cave-man technique of commenting out the calls/hooks to OnUpdate in every nUI source file, one by one, and watching how the usage for nUI as a whole changed in the addon I mentioned (Broker_CPU Memory).

There were no noticeable changes, except for nUI_Button and nUI_UnitAura where it was dramatic.

I do suspect that at least nUI_Button could be recoded for improved performance more or less in isolation. I don't claim to have understood the whole thing (yet) but it is only about 1K lines of executable code, and it only does a handful of things. It might require giving up a few of the less important graphical embellishments, and fighting less against what the Blizzard code tries to do, but it would save a lot of duplication of effort (e.g. checking each action for range/usability/mana just after the Blizzard code has done exactly the same thing).

The "value-added" by nUI_Button, as far as I can tell, is pretty much the cooldown and debuff timer. It's hard to imagine that should require 6% of an i7 core, even in a less than perfect architecture.

You're more than welcome to have at it if you like. I'm avoiding investing my own time in nUI5 as I have precious little enough of it as it is. But I'll gladly take cues should you hit on any specifically interesting modifications.