PTS issue, or?

[Fyrakin]

Originally Posted by merlight I tried to explain that there's no reason to compute the root if you only need it for comparison against some distance threshold. Additionally, each sub-expression should only be computed once -- it's both more efficient and readable. Like this function, it does way too many avoidable table lookups and an unnecessary sqrt: local function IsCoordinateInRange(x, y)     if not FyrMM.currentMap.TrueMapSize or not FyrMM.currentMap.PlayerNX or not FyrMM.SV.CustomPinViewRange or not FyrMM.SV.ViewRangeFiltering then return true end     return FyrMM.currentMap.TrueMapSize * math.sqrt((x-FyrMM.currentMap.PlayerNX)*(x-FyrMM.currentMap.PlayerNX)+(y-FyrMM.currentMap.PlayerNY)*(y-FyrMM.currentMap.PlayerNY)) <= FyrMM.SV.CustomPinViewRange end -- this is used so heavily that I'd localize it at the file level local g_currentMap = FyrMM.currentMap   local function IsCoordinateInRange(x, y)     local mapSize = g_currentMap.TrueMapSize     local nx = g_currentMap.PlayerNX     local pinViewRange = FyrMM.SV.CustomPinViewRange     if not (mapSize and nx and pinViewRange) then return true end       local dx = x - nx     local dy = y - g_currentMap.PlayerNY     return (dx * dx + dy * dy) * mapSize * mapSize <= pinViewRange * pinViewRange end

It is a very fast changing environment, btw this particular function works fine no difference between live and pts. I made heavy changes during past week meantime testing it against pts and speeds are looking acceptable. Though it runs much smoother on live.

PS I also have noticed a faster garbage collection growth while using local variables. This is very worrying.

[Sasky]

Originally Posted by Fyrakin It is a very fast changing environment, btw this particular function works fine no difference between live and pts. I made heavy changes during past week meantime testing it against pts and speeds are looking acceptable. Though it runs much smoother on live. PS I also have noticed a faster garbage collection growth while using local variables. This is very worrying.

What merlight is trying to say is that finding the square root is a computationally expensive operation and should be avoided if at all possible. If sqrt( A ) < sqrt( B ), then A < B for distances.

I'd look at what else you're doing in the function because local variables by themselves won't noticeably increase GC time ( http://lua-users.org/wiki/OptimisingGarbageCollection ). In fact, it's generally an optimization to copy over to local from a global table, especially if you're going to access it frequently. (http://lua-users.org/wiki/OptimisingUsingLocalVariables)

For example, looking up "FyrMM.currentMap.TrueMapSize" actually needs 3 table lookups: FyrMM in the Global table, currentMap in FyrMM, and TrueMapSize in currentMap. Bringing it to a local variable caches it so that when you access it the second or third time it's already present.

[Fyrakin]

Originally Posted by Sasky What merlight is trying to say is that finding the square root is a computationally expensive operation and should be avoided if at all possible. If sqrt( A ) < sqrt( B ), then A < B for distances. I'd look at what else you're doing in the function because local variables by themselves won't noticeably increase GC time ( http://lua-users.org/wiki/OptimisingGarbageCollection ). In fact, it's generally an optimization to copy over to local from a global table, especially if you're going to access it frequently. (http://lua-users.org/wiki/OptimisingUsingLocalVariables) For example, looking up "FyrMM.currentMap.TrueMapSize" actually needs 3 table lookups: FyrMM in the Global table, currentMap in FyrMM, and TrueMapSize in currentMap. Bringing it to a local variable caches it so that when you access it the second or third time it's already present.

I know , I'm not new into LUA.

[merlight]

Originally Posted by ZOS_ChipHilseberg Saving performance took a hit because of some changes over the past six months (introducing an intermediate buffer), but we've restored the performance internally and will be fixing that before 1.7 launches. Performance of the VM itself is not a known issue however. We have not noticed any changes to the performance of the stock UI. If you learn more, please let us know.

I wonder... we refer to 1.7 because we're used to counting big updates since launch, of which there were six. And then marketing came with 2.0 -- which amounted to unlocking the Crown Store -- as if that update was bigger than all before it I find it somewhat comforting that you still count updates and not items-of-the-month

[QuadroTony]

2.1.7

Fixed an issue where using /reloadui would occasionally freeze your screen for up to a minute before entering the loading screen.

looks like fixed?