Re: Issues with the current varargs implementation (Was: Re: inadequate documentation for select and table.unpack)

[Martin <eden_martin_fuhrspam@...>]

On 16-06-23 07:49 AM, Daniel Stephens wrote:
> In practice for performance sensitive code making a lot of use/re-use of
> a result of a particular UI call, it was generally better to stick it in
> a table (if possible a re-usable scratch table) - though the exact sweet
> spot was something you'd have to determine for each situation.
> 
> Daniel (Iriel).
> 

Nice to meet person who worked with WoW API!

Yes, this is good approach. But I doubt Blizzard will ever do this.

Last time I dealt with WoW API there was near thousand functions in _G.
They began to structurize them in tables in newer facilities like pet
battles or garrison. But it looks like things like UnitAura() (which may
return 16 results for every of 40 auras for any unit) will remain forever.

And looks like instead of real solution with shared tables they just
shift problem out from their side.

For about three years I developed pvp bot for personal usage and
amusement (it used lua unlocker which just enables protected functions
like CastSpellById(). So technically it had same possibilities as any
player. Except superhuman reaction time.). To react quickly it had to
scan units frequently, about 5-20 times per second. There I faced
problem that writing nice code like

"unit[GUID].aura[i] = annotate_array({UnitAura(unit_name)},
UnitAura_result_names)"

I yields to heavy garbage allocation. To avoid it I began to store
.last_scan_time and handle events to directly update fields.

I'm sure many other "legal" addons face same problems. For example when
displaying health/energy/casting bars.