Originally Posted by boomboo
It's not especially surprising since UnitAura is implemented in C (I presume), and might have it's own caching or optimizations. Adding stuff on top of it in lua doesn't help.
|
Test again, but instead 'nothing' use the name of an aura you expect to find (like cast Rejuvenation on yourself and run the test with it). The cache is twice as fast (this is the best case however, since because of the use of GetTime() and the test freezing the client, the cache is hit every time except for the initial call)
Originally Posted by Edik
I agree. GetTime() changing every frame update. When you have low FPS it could change only few times per second. But auras change few times per second as well if you care just about aura existence not about startTime, endTime is fine. That was target for these wrappers, just make code works at least in 8.x and do some backward compatibility.
|
Auras do not necessarily change that often. If GetTime() works as you intended it to run, you will have 10 times per second the worst case, which is 4 times slower than the direct loop over all auras. Also you don't invalidate the cache if the unit changes (I target another mob), so it might be possible to even get wrong results from hitting the cache (you might argue that I'll call UnitAura again soon enough to not even notice this, but it is still possible).
From my perspective a wrapper should be just that and not a cache on top of it.
The interesting part is the gap in performance between best and worst case and it makes it clear how inefficient your UnitAura calls are. You pack the results of UnitAura in a table and unpack it later for return. You also have all the table look-ups in between. What is the benefit from that? Also
lua Code:
local index, filter = ...
is the same as
lua Code:
local index, filter = select(1, ...)
but without the added function call.