mirror of
https://github.com/brues-code/SuperCleveRoidMacros.git
synced 2026-09-16 03:38:00 +00:00
Brues
f296425c94
Chasing high memory churn (~188 kb/s with pfUI). Four allocation sources and one correctness bug found along the way. The recurring cause: in 1.12's Lua 5.0 a function declared `function(...)` builds a fresh `arg` table on every call. Three handlers were declared that way and none of them read the vararg. - Compatibility/pfUI.lua: the registered action handler. This was the dominant one. UpdateAllManagedCooldowns fans ACTIONBAR_UPDATE_COOLDOWN across every managed slot (up to 120) on each SPELL_UPDATE_COOLDOWN, so every GCD and cooldown tick allocated ~120 tables that the handler then discarded, because its whole body only ever applied to ACTIONBAR_SLOT_CHANGED. Dropped the vararg and added an early return before any work. Bongos' and UltimaMacros' handlers were already vararg-free. - Core.lua SendEventForAction: dropped the vararg (every caller passes exactly one extra value) and replaced the inline "arg" .. i concatenations -- 30 per call across three loops -- with a prebuilt name table. The eight-branch arg.n fan-out collapses to one loop. - Core.lua Frame OnEvent dispatcher: dropped the vararg. It fires for all ~48 registered events, including the UNIT_HEALTH / UNIT_AURA / UNIT_*_GUID streams. PublishDisplay now skips no-op publishes. Publishing is not free: the client repaints holders of the macro through its own notifier, which returns as ACTIONBAR_SLOT_CHANGED -> ClearAction + IndexActionSlot -> TestForActiveAction -> publish. Publishing an unchanged value therefore tore down and re-resolved slots for nothing and fed itself, since GetAction and IndexActionSlot both publish on paths that fire constantly. This was the C_Macro.SetMacroDisplay regression. Also merges the two same-named SPELL_CAST_EVENT handlers. Lua assigns in file order, so the later definition silently replaced the earlier one and its half never ran: channel-start detection, spell_tracking cleanup, and cast-sequence advancement. AdvanceSequence has only two callers and the other is inside UNIT_CASTEVENT, which is registered only under SuperWoW -- so /castsequence had no way to advance on a successful cast for Nampower-only users.