well if i create a spell for dynamic coloring of units i need to begin to worry about speed =)
the feature is what map (playable) contains of alot simple parts but together they take some performance. so you need to watch what are you doing.
ofc in "static" aplications speed is not really essential.
and one thing...
You seem to have the idea that SetUnitVertexColor(u, red[a], green[a], blue[a], alpha[a]) is incredibly much faster than the .recolor method in here. For a guy that has made a playable map (I guess that now counts as an achievement) you seem to have a wrong idea of what is fast and what isn't, or the scale in which something is faster than the other. You actually sound very alarmist about speed sometimes yet other times use something that causes more speed issues that another thing. I think a really experienced Jasser (and I am yet to see one) would have made an actual benchmark before making claims, instead of using his playable-map-maker license...
I guess, the recolor method is much slower than SetUnitVertexColor(u, red[a], green[a], blue[a], alpha[a]), if much slower means 0.1%? or 1% or 100%?. Let's even forget about .create() and .destroy() and the fact that you are making a periodic timer that changes a unit's vertex color every 0.025 seconds... let's assume the bottleneck is with the divisions (it's amazing how these divisions are so evil in comparison to array lookups in these color utilities functions yet so good when we are comparing hash tables with array lookups)
Let's also forget that if you used normal structs mix() will actually need to call create() in order to work in the same way, and that application of recoloring some unit with a periodic event - I guess it is all about the mix function, else it wouldn't make any sense to be doing that periodic recoloring anyway. Let's add a call to create() to the mix() function because we care so much about speed... When you think about it, mix will still need R2I calls, double multiplication, division and addition regardless of whether you used struct members or not, But the integer division used in the .recolor method is obviously much worse.
Of course, there are workarounds, like modifying the mix function so it takes 3 arguments, now the code to use has gotten more complicated, but who cares? Speed is what matters here, you will still be calling mix() which is obviously
a huge problem performance-wise... I got an idea! Since we like speed so much, let's instead preload the colors to be used in the periodic loop! That should work!
... but, we could have preloaded the colors into groups of four r,g,b,a variables anyway if we sticked to the original implementation of ARGB... So much work for nothing.
displayed code... after preproccesing it will become X times larger.
But your idea of a single struct holding red green and blue will get larger than that. Oh and if you wanted to get rid of the 8190 limit, much, much larger.
In my opinion, making something equivalent to this using struct members (and I mean equivalent in functionality) would require you to have like a big instance limit since you are not ever going to use .destroy() or .create whatsoever . Because of this, you would need function calls to get the values for red green and blue... If you made an equivalent thing using struct members, it would get slower.
Something to consider is that speed is not the focus here, because at the end of the day, not using this script and doing everything manually, not even with structs but with local variables r,g,b,a is many times faster, any optimization making it use members instead of encoded integers would be worthless, the fastest way is to do all the mixing manually. So, you may be wondering up, what's the point of this script if it isn't the fastest way possible? Sometimes things are not meant to speed execution up, but to speed development time up... I know you, it is very hard for you to accept the fact someone would be more interested in reducing development time rather than performance time. But I got to say, almost everybody out there that is making actual playable maps
rather than demos or ego projects, cares more about releasing his maps soon than about speeding up a function by 1%, speed is nice and all, but Jass being an interpreted language, there is sometimes no point really in using something that is faster than something else when the time to code it, implement it and debug it would be much larger than the alternative, unless the difference in performance is really big, but that would be things like O(n^2) vs. O(n) rather than things like division vs. arrays... If we were talking about a freaking game engine instead of changing the color of a unit every 0.025 seconds using an interpreted language, speed would matter much more, sadly we are not.
Everyone can make a playable map, I did, you did, who cares? There's something you are missing greatly and it is that not everybody wants to spend 2 or 3 years making a map, the worst thing that could happen is that they end up taking so much time that when they finish it there really are no players left, perhaps if they speeded the development up of their map instead of going ultra low level just to get 1% more speed in one function they would have finished their map much before, perhaps by the time Allstars was released... instead of 2008...