Is SetUnitPosition faster than SetUnitX/Y

[Deleted member 219079]

I'm all about speed, and if there is even 1% difference please tell me

 

[deathismyfriend]

No SetUnitPosition is slower.
SetUnitPosition checks for pathing.

SetUnitX/Y don't check anything they just place the unit at the coordinates.

 

[Deleted member 219079]

Thanks for response!


SOLVED

 

[Dr Super Good]

SetUnitPosition I would imagine being faster in some cases (nothing nearby to path with). However it is very costly if moving a unit into something as the displacement algorithm can even cause entire frames to be dropped due to execution length.

 

[Deleted member 219079]

SetUnitPosition I would imagine being faster in some cases (nothing nearby to path with). However it is very costly if moving a unit into something as the displacement algorithm can even cause entire frames to be dropped due to execution length.

My dummy has a movement type of none and pathing size of 0, could SetUnitPosition be faster for it?

 

[deathismyfriend]

@DSG
How would SetUnitPosition ever be faster ? It uses more processing power just to run it. If I remember correctly nes said it uses 12 bytes compared to 3 bytes from SetUnitX and 3 bytes from SetUnitY.

 

[Dr Super Good]

How would SetUnitPosition ever be faster ?

Most of the processing of most natives is the actual parsing of them in the JASS interpreter as all names involved are dynamically looked up in interpreter fashion. SetUnitPosition should take only 2 arguments (maybe 3 if they force a facing). SetUnitX/Y will be at least 4 arguments parsed and 2 natives resolved. The end is 3-4 name resolutions against 6. Actual native code executes pretty fast so for most cases performance is entirely JASS related. The obvious exception is the displacement which even simply spawning units from a building can drop frames in crowded situations but other times is not noticeable.

This is why there is no real measurable performance difference between reals and integers despite in reality floats being a lot slower. JASS is just very slow.

 

[BPower]

I'm all about speed, and if there is even 1% difference please tell me

Should never be your first concern, it's the first stupid mistake many people make.
In your case the correct answer is: if you need a pathing check use SetUnitPosition, if not use SetUnitX/Y.

 

[Nestharus]

@DSG
How would SetUnitPosition ever be faster ? It uses more processing power just to run it. If I remember correctly nes said it uses 12 bytes compared to 3 bytes from SetUnitX and 3 bytes from SetUnitY.

I don't remember saying this o-o

SetUnitPosition always runs pathfinding, even if there is nothing there. SetUnitX and SetUnitY in a map with only 1 unit will run faster than SetUnitPosition. I have benchmarked this. SetUnitPosition is half the speed of SetUnitX + SetUnitY (approx), even with nothing there. With stuff there, it runs even more slowly.

As BPower said, if you need path checking, use SetUnitPosition. If not, use SetUnitX + SetUnitY.

DSG, you should know that name resolution is inconsequential compared to the bs algorithms that Blizzard uses = P. Actually, name resolution can be pretty nasty too... lmao. A very long variable name will take a very long time to resolve =D

 

[Deleted member 219079]

Should never be your first concern, it's the first stupid mistake many people make.

I mean I like to minimize the amount of native calls I make in my loops.

In your case the correct answer is: if you need a pathing check use SetUnitPosition, if not use SetUnitX/Y.

I don't, so I'll use SetUnitX/Y, just like I've used before.

I just saw a script using SetUnitPosition so this got my mind wondering, but now I've got a confirmation to this.

Thanks for explanations, I'd rep you but I've given too much rep today.

 

[Dr Super Good]

I have benchmarked this. SetUnitPosition is half the speed of SetUnitX + SetUnitY (approx), even with nothing there.

Were these testing the function alone or with location creation and destruction? Obviously it performs a lot slower if you involve the location object creation and destruction since that has a huge resolution overhead but that was not the question give.

 

[Nestharus]

Huh?

native SetUnitPosition takes unit whichUnit, real newX, real newY returns nothing

native SetUnitX takes unit whichUnit, real newX returns nothing
native SetUnitY takes unit whichUnit, real newY returns nothing

Also -> http://www.thehelper.net/threads/setunitposition-vs-setunitx-setunity.51558/#post-450924

Grim's reply is on that thread

 

[Dr Super Good]

Oh I thought it was the Location based one that GUI uses, my mistake.

 

[deathismyfriend]

I don't remember saying this o-o

SetUnitPosition always runs pathfinding, even if there is nothing there. SetUnitX and SetUnitY in a map with only 1 unit will run faster than SetUnitPosition. I have benchmarked this. SetUnitPosition is half the speed of SetUnitX + SetUnitY (approx), even with nothing there. With stuff there, it runs even more slowly.

As BPower said, if you need path checking, use SetUnitPosition. If not, use SetUnitX + SetUnitY.

I'm sorry if it wasn't you nes. I thought it was. Maybe it was maker then. I'm not really sure who told me though.

 

[PurgeandFire]

Note: SetUnitPosition also issues a stop order (which can add extra overhead, and it can fire other triggers that respond to order events, so it is even more expensive in that case). As a consequence, SetUnitPosition will also interrupt animations and orders (since it issues a stop order). Use that, combined with the overhead of the pathing check, to make your decision.

SetUnitX/Y is pretty much always better. Even when you need pathing checks, it is probably better to just use a pathing-check system (combined with SetUnitX/Y), unless you're okay with the stop order & its consequences.

 

[Dr Super Good]

It should be noted that due to a lack of a pathing check, SetUnitX and Y can be dangerous (well more dangerous as the other is not totally safe) if used near the edges of the play field. Units trying to go off the edges of the play field can result in fatal errors. As such often extra tests are needed during use.