[PERFORMANCE] even faster get_turf

[Erik]

See title.

Patch: Here
Code: Here

[Noah Buttes]

I don't know why, but I get the feeling that this would probably break a bunch of things.

I'm probably wrong though.

[Erik]

I don't know why, but I get the feeling that this would probably break a bunch of things.

I'm probably wrong though.

I've done some basic tests, and i have been unable to find any cases where this would break the normal get_turf behavior, it's just slightly faster.

[Noah Buttes]

I don't know why, but I get the feeling that this would probably break a bunch of things.

I'm probably wrong though.

I've done some basic tests, and i have been unable to find any cases where this would break the normal get_turf behavior, it's just slightly faster.

There doesn't seem to be an answer to the question of whether this is intended behavior in the thread you linked in your patch.

It might be a good idea to hold off on implementing this live until we get some form of confirmation.

[Erik]

Giving this a friendly bump as it's been confirmed by Lummox to work just fine.

get_step(Ref,0) is a really innovative idea; you're right that it's calling an internal routine to get the turf. The downside is, it's also doing a call to LocXYZ() and then XYZLoc() even if there's no direction given, so it's unpacking and then re-packing the coordinates for no reason. (That's two divisions and two multiplications.) However it definitely is stable and intended behavior, so you can rely on this to work. A sanity check for dir 0 would speed this up in that case, but obviously it would just be dead weight on all other get_step() calls.

At the moment there are no other quick shortcuts to the internal GetLocTurf() function.