Thread: oUF performance
View Single Post
09-26-18, 07:26 PM   #4
lightspark
A Rage Talon Dragon Guard
 
lightspark's Avatar
AddOn Author - Click to view addons
Join Date: Sep 2012
Posts: 341
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)
Originally Posted by Blooblahguy View Post
* Localizing variables outside of for loops, also a massive performance increase
Oh, that's a hot topic when we're prepping oUF 7.0, which was a major revamp. After discussing it for months, we chose not to do such optimisations. In general, it's not really needed, unless you're running loops w/ literal millions of iterations, performance gains from using local functions over global ones are kinda marginal. TBQH, in the addon dev community this thing is seen as a preference, not a necessity.

However, if it's something major, e.g., the 300% cases you've just mentioned, we, at least I personally, would like to hear about those.

Originally Posted by Blooblahguy View Post
* Creating tables or table templates(key sizing) outside of loops and just updating their reference inside of loops
Examples? o_O

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.
That's a bad idea, we don't have any control over what data Blizz APIs send us, it's entirely possible to get a different result while using the same params because something on the back end decided so.

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.
It's necessary to update all elements OnShow because there's no way to know if something about that frame's unit has changed, even if it's somewhat persistent like "player", although even it can be replaced w/ "vehicle" sometimes, but something like "target" or "nameplate*" is often pointing at different PCs/NPCs when they re-appear on your screen.

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 try to use OnUpdate only when we really have to, if you find problematic ones, feel free to point them out. But, please, don't try to replace OnUpdates w/ coroutines

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. Same goes for nameplates.
We absolutely shouldn't be doing this. You can't disabled nameplates completely, Blizz force the UI to use friendly nameplates in raids/dungs, moreover, despite various parts of Blizz UI being located in the AddOns folder they shouldn't be treated as such. Many of them are often referenced w/o any safeguards from the main UI code that's in the FrameXML folder, Blizz basically expect them to be enabled at all times.

As for Blizz compact raid frames, it's up to layout devs to disable them.

I think Blizzard_ArenaUI is the only exception we make, which is shady enough, and we'll prob rework it.
__________________

Last edited by lightspark : 09-27-18 at 06:14 AM.
  Reply With Quote