Thread: oUF performance
View Single Post
09-27-18, 04:02 AM   #5
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Optimizations are always welcome, but they should be backed with proper profiling. You're listing a lot of micro optimizations that probably won't have a lot of impact on the bigger picture.

Originally Posted by Blooblahguy View Post
* Localizing common functions in each script. Things like UnitAura / UnitBuff / UnitDebuff / UnitReaction / UnitThreatSituation and so on. There are easily 100 functions that could be localized and localized function references are a minimum of 30% faster (i've profiled in some cases up to 300% faster)
* Localizing variables outside of for loops, also a massive performance increase
You do save some by making globals local, but we're talking about maybe 10ms over 100k calls.

Putting locals outside of loops has a even smaller gain. The only place that would have made sense is in the aura element and I'd rather take the cleaner code over a minor optimization there.

Originally Posted by Blooblahguy View Post
* Creating tables or table templates(key sizing) outside of loops and just updating their reference inside of loops
We're already re-using (frame) tables in oUF, so there isn't really anything to be gained by this. With the aura element we could split the icons and options into separate tables, so we could benefit from Lua's array table behavior. I don't think it's worth breaking the API over it however.

Originally Posted by Blooblahguy View Post
* Result memoizing - I believe this is possible in WoWs implementation, but storing some function results so that when the same function parameters are given, it simply returns the same result as the last time rather than recalculating. This can be useful for common calls such as UnitName or internal functions that use unique string names as input. `unit` changing frequently might make this difficult to implement on things like nameplates or raid frames. Food for thought.
We would trade some CPU time for a lot of memory doing this. Since most functions return multiple values and take various input depending on element/layout/etc.

Originally Posted by Blooblahguy View Post
* I've noticed that OnShow can result in all of a frame elements forcing an update, which seems likely unecessary and a huge resource hog for frames that hide and display frequently.
With some work we could flag hidden frames as dirty, depending on event/unit combination that was called while it was hidden. Not sure how much of an impact this would make and if it's worth the extra complexity.

Originally Posted by Blooblahguy View Post
* There are also OnUpdate script in a number of default elements which do a lot of calculation that I think should be revisited
We could probably throttle castbar and runes to only update every 16ms, but it needs to be pro filed to see if it's worth it or not. range, tags and frame's OnUpdate are already throttled.

Originally Posted by Blooblahguy View Post
* Default blizzard addons tend to continue to run even when hidden and their main driver has events unregistered. Once their frames are created they have subevents registered and still seem to be firing an unbelievably high amount. I think when we spawn raid frames, we should DisableAddon on Blizzard_CompactRaidFrames, on nameplates DisableAddon Blizzard_Nameplates, so on so forth. I've been profiling these frames and they are absolutely decimating performance when they should be disabled. I was finding that addons like WAs were holding up > 3s of cpu time over the course of a raid fight, but that just CompactRaidFrame_Unit1 was upwards of 80s.
This is probably where the real meat is. Fixing this is probably a larger gain than all other points combined.
__________________
「貴方は1人じゃないよ」
  Reply With Quote