Everyone who uses GUI so like >90% of people.At least I didn't try to mess with boolexpr ops And, Or and following (who the hell uses them anyway?)
GUI isn't topic of discuss anyway, here's real jassers speakinEveryone who uses GUI so like >90% of people.
could you provide the code?1.26a is affected by this for sure, dont know about 1.27+
Except BLP files. Which are now slightly less broken and more strict.blizz didnt change a fuck during new patches, dont worry, everything broken is still broken
well they fixed some stuff with lightnings and other stuff, but here we are speaking of jassExcept BLP files. Which are now slightly less broken and more strict.
wc3 < 1.24 ?This is small comparison between structs/arrays, hashtables and gamecache.
The idea for it comes from Tc's XColl (600 Spheres) but this version is not as cool =).
I'm interested in a modern (1.27+ working) version if anyone sorts it out.
Do passive abils counts? It would be a dramatic decrease with bonus systems since they overload unit with passivesanytime unit performs any action (move/attack/order/selection/etc) there's loop through all his abilities for looking which of them would like to trigger on this action. So, for those who cares about nanoseconds, another tip - decrease amount of abilities your units use. it will help a lot (comparing to other microoptimizations)
literally any. every ability may have callback for an action, and game never knows, so re-check everytimeDo passive abils counts? It would be a dramatic decrease with bonus systems since they overload unit with passives
Do passive abils counts? It would be a dramatic decrease with bonus systems since they overload unit with passives
Ok theb.literally any. every ability may have callback for an action, and game never knows, so re-check everytime
Can we? I don't remember any tome ability increasing, for example, armor or sight radiusAnother reason to use Tomes instead, imo.
I wouldn't think about it being "dramatic". DracoL1ch specifically mentioned "nanoseconds" and in Bonus systems that applies a binary approach for giving bonuses, the probability of having most number passive abilities at once is 1/(2^n) where n = number of abilities. Say the bonus system uses 12 abilities (-4096 to +4095 possible bonus damage), the only time your unit would have all 11 abilities is you applied +4095 bonus damage. Most of the time, we can estimate (or average) that the unit would have 6 extra abilities or n/2 (half of the total abilities). With that said, I would still very much use Bonus system after knowing this information. It's an interesting info but I don't think it affects much.Do passive abils counts? It would be a dramatic decrease with bonus systems since they overload unit with passives
Well -1 is worse than maximum + by one ability.I wouldn't think about it being "dramatic". DracoL1ch specifically mentioned "nanoseconds" and in Bonus systems that applies a binary approach for giving bonuses, the probability of having most number passive abilities at once is 1/(2^n) where n = number of abilities. Say the bonus system uses 12 abilities (-4096 to +4095 possible bonus damage), the only time your unit would have all 11 abilities is you applied +4095 bonus damage. Most of the time, we can estimate (or average) that the unit would have 6 extra abilities or n/2 (half of the total abilities). With that said, I would still very much use Bonus system after knowing this information. It's an interesting info but I don't think it affects much.
actually I was wrong, as usual when it comes to opsbit faster thanJASS:set b=not b
sentence, like ~40%. probably because game have to parse 3 ops (get the b, get the == equialent, cast false to 0) instead of 2 (get the b, get the 'not')JASS:set b=b==false
leandrotp said:not X is just 2 operations:
GETVAR R1, X
NOT R1
X == false is 5 operations:
GETVAR R1, X
PUSH R1 //Why they compile this with a fucking PUSH?
LITERAL R2, 0
POP R3
EQUAL R2,R3,result
===================================
5000 iterations of ExecuteFunc took 38 milliseconds to finish.
5000 iterations of Call took 3 milliseconds to finish.
Call was 1166.667% faster than ExecuteFunc
===================================
5000 iterations of UnitAlive took 3 milliseconds to finish.
5000 iterations of GetWidgetLife took 4 milliseconds to finish.
UnitAlive is 33.33% faster than GetWidgetLife
===================================
5000 iterations of SetUnitPosition took 166 milliseconds to finish.
5000 iterations of SetUnitX/Y took 10 milliseconds to finish.
SetUnitX/Y was 1560.000% faster than SetUnitPosition
===================================
5000 iterations of ForGroup took 112 milliseconds to finish.
5000 iterations of FirstOfGroup took 4 milliseconds to finish.
FirstOfGroup was 2700.000% faster than ForGroup
Please compare SetUnitX/Y with the new SetSpecialEffectPosition native?
5000 iterations of SetUnitX/Y took 11 milliseconds to finish.
5000 iterations of SetSpecialEffectPosition took 8 milliseconds to finish.
SetSpecialEffectPosition was 37.50% faster than SetUnitX/Y
Only that it also has the overhead of enter-region events. I bet if the code were switching the unit between regions (with an event attached) you'd see a huge spike.Set*X/Y operates with all the same structure innerly, it's more about random delays and memory cache when you compare them
It also has "unit in range" overhead (which might be the same as aura update overhead, though that does lag noticeably behind quickly-moving units).Only that it also has the overhead of enter-region events. I bet if the code were switching the unit between regions (with an event attached) you'd see a huge spike.
In the instances being dealt with here, the dummy unit is likely to have the Locust ability and therefore not trigger auras or unit-in-range events.It also has "unit in range" overhead (which might be the same as aura update overhead, though that does lag noticeably behind quickly-moving units).
I tested a few times and got consistent results.
Code:5000 iterations of SetUnitX/Y took 11 milliseconds to finish.[/FONT][/LEFT] [FONT=Verdana] [LEFT]5000 iterations of SetSpecialEffectPosition took 8 milliseconds to finish. SetSpecialEffectPosition was 37.50% faster than SetUnitX/Y
You're right to say it wouldn't trigger any unit-in-ranges nor be subjected to any auras. Unless I am mistaken, even locusted units propagate their own auras (I know they wouldn't have any if they're units-as-sfx) and it would still need to check if any 'unit in range' events have been applied to the moved unit (though there wouldn't be, or unless the game doesn't check/fire those triggers when the source of the event gets moved). The check for it having any auras and for it having any unit-in-ranges associated with it have to add some bit of overhead there.In the instances being dealt with here, the dummy unit is likely to have the Locust ability and therefore not trigger auras or unit-in-range events.
I'm not suggesting anywhere that they have anything to do with each other, and I don't think anyone is suggesting in that this optimization functionally matters except in extreme scenarios. This discussion is about curiosity regarding the difference between old natives we know and new natives we don't, and what contributes to their difference in execution. I'm not arguing with anyone, rather stating two further things that might cause additional overhead if they're actually relevant to UnitXY calls. For the curiosity, dude, not for obsessive code efficiency.unit in range event has nothing to do with auras, auras perfomed in simple timers
you overthink this shit. Remember collect corpse ability from meat wagon? It makes a call for searching a corpse each time it's coordinates change. Literally. A fucking each time. 10k calls each second while it moving somewhere. And still game going just well with that. Look into other directions.
It is more likely to be a call every 0.10 seconds, like the UnitInRange events.unit in range event has nothing to do with auras, auras perfomed in simple timers
you overthink this shit. Remember collect corpse ability from meat wagon? It makes a call for searching a corpse each time it's coordinates change. Literally. A fucking each time. 10k calls each second while it moving somewhere. And still game going just well with that. Look into other directions.
just saying these kind of data oftenly being used as "FASTER MEANS EVERYONE SHOULD CODE LIKE THAT" in the internet.
what are you talking about? Im displaying long tested data, and 0.1 is too low for ingame stuff.It is more likely to be a call every 0.10 seconds, like the UnitInRange events.
Relax. I would like to see that data.what are you talking about? Im displaying long tested data, and 0.1 is too low for ingame stuff.
set b=GetOwningPlayer(u)==p
set b=IsUnitOwnedByPlayer(u,p)
What post is this aimed at?On which NUMA nodes were you pinning your cores? Have you tried extracting a part of the API into SDL to run on a PCB?
JASS is converted to bytecode to run, however the byte code is not statically linked. All variables are referenced by name rather than directly as an address, hence a hashtable look up operation is required which has a O(n) complexity string hash algorithm.All of those been said long ago, but I didn't believe it because jass pre-filter everything to byte code before we start, so how could names ever affect it if names are never used but indexes of variables? Well, they are used for some reason.
any explanation for dummies? Because in bytecode all those vars are referred by index, means they are pre-parsed, but then for some reason it restores var's name basing on indexJASS is converted to bytecode to run, however the byte code is not statically linked. All variables are referenced by name rather than directly as an address, hence a hashtable look up operation is required which has a O(n) complexity string hash algorithm.
v12 = sub_6F44B2C0_VariableIDToStringName(*(_DWORD *)(v5 + 10328), v7);
sub_6F44CBC0_JASSVM_GetVariableAddress((int)v11 + 144, v12);
any explanation for dummies? Because in bytecode all those vars are referred by index, means they are pre-parsed, but then for some reason it restores var's name basing on index
in pseudo-code literally every access looks like that
Code:v12 = sub_6F44B2C0_VariableIDToStringName(*(_DWORD *)(v5 + 10328), v7); sub_6F44CBC0_JASSVM_GetVariableAddress((int)v11 + 144, v12);
TriggerRegisterVariableEvent
), and then when implementing the Jass VM, it was just easier to restore the string from the id and call the by-name lookup, instead of wasting time implementing a way to lookup directly by the string id. And speed was never a concern, when they were creating the Jass language and the interpreter, they couldn't possibly imagine that the modding community would become as big as it is.What's Loop()?Turned out, even for 6-units group ForGroup is still 2x slower than Loop().