Originally Posted by Vexorian
You should consider that maybe a filter could be useful so that in certain hypothetical maps, units that keep getting changed colors periodically but do not use this do not harm performance too much.
I thought the hook was the main performance drain and there's no way to filter that, but you remind me that in the case of colour the ARGB.create is an additional function call that does a bunch of maths, so in this regard filtering could speed things up a bit; however, couldn't that ARGB method be made inlineable by reordering the use of arguments in the equation?
Then, in the best case (if you're using AutoIndex), the cost of the hooked code would only be a GetUnitId call, some integer multiplications/additions and an array set, which compared to the overall cost of hooking (function call, evaluate with a bunch of arguments) and compared to the potential costs of filtering (at best an inlineable function that does a UnitTypeId check or a GetUnitUserData call plus an array read) doesn't seem like much, unless I'm completely overestimating the speed of integer maths.
Perhaps you could use a third static condition to use a native hashtable. I would prefer it to use AutoIndex or Table instead of messing with the hashtable limit, but I guess others would disagree.
Yes, in this case both Table and AutoIndex would be optional requirements. The problem with that is that global declarations ignore static ifs so I couldn't declare the needed global Tables - I'd need to either store them in global integers and typecast them all the time, which although it doesn't affect performance is just ugly, or I'd need to make them into static variables in a dummy struct since those do get properly eliminated by static ifs. Neither solution looks pretty, but neither also has any functional problems so if enough people with an aversion to Table show up and post here then I could be convinced to make this change.
Thanks for the review.