PTS issue, or?

[QuadroTony]

everytime on PTS when i /reloadui i kicked from a game to login screen

any1 experienced it too?
no matter what addons i use


P.s. sorry looks like it because of addons

will investigate

P.S.S - looks like the longer you play - more chance of kick and more time of reloadui wasting
everytime

weird

[Ayantir]

I got difficulties too with reloadui too, but for me it's most a freeze, Maybe im not enought patient. maybe it's one of my addons aswell..

[Fyrakin]

On PTS /re or /reloadui makes my client freeze for 5-30 seconds before loading screen, but no kick outs.

[Ayantir]

for the freezes, that's definitively an (more than one?) addon issue, with only very few, there's no freeze, i'll try to check which one cause this..
Guess Quadro just got too many addons but get same issue as us.

[Fyrakin]

Originally Posted by Ayantir for the freezes, that's definitively an (more than one?) addon issue, with only very few, there's no freeze, i'll try to check which one cause this.. Guess Quadro just got too many addons but get same issue as us.

Probably, but nothing like that happens on live version.

[QuadroTony]

Originally Posted by Ayantir for the freezes, that's definitively an (more than one?) addon issue, with only very few, there's no freeze, i'll try to check which one cause this.. Guess Quadro just got too many addons but get same issue as us.

no-no-no

on pts i have like 5 addons at all

[merlight]

Same here, with ~35 add-ons /reloadui freezes for a while, but no crash. Also, after /quit, the process keeps running for ~30s, 100% load on 1 core, with >50% its time spent in system calls. I wonder what it does, as memory usage stays nearly the same during that time, and only drops right before it finally terminates.

[QuadroTony]

and if you instant logout(in cities)

picture can freez alot before load-out screen

[ZOS_ChipHilseberg]

Well this sounds troubling. What addons were you using Tony?

[ZOS_ChipHilseberg]

Also can anyone compare the behavior on RC to Live? In all of my internal profiling I was seeing faster write times, not slower.

[QuadroTony]

i recorded the video now

starting without addons and then i playing alittle and turn on addons one by one
i dont think the problem is in particular addon

looks everytime after /reloadui pause before load screen was bigger and bigger and in the end - Error 303 server timed out

i player 30 minutes
and strange thing as you can see - one on the cores of my CPU was heavily loaded when i was kicked

http://www.youtube.com/watch?v=ctnGY8ptuus

[ZOS_ChipHilseberg]

Thanks Tony, we now have an internal test case for this.

[Fyrakin]

Originally Posted by ZOS_ChipHilseberg Also can anyone compare the behavior on RC to Live? In all of my internal profiling I was seeing faster write times, not slower.

My figures are astounding, using just a few add-ons that run like a rabbit on steroids on live make PTS choke up after running for a few minutes. I also noticed that collectgarbage("count") is filling very fast (too fast) compared to live. Maybe that's the problem?
I'm trying to alter my add-on to run faster on PTS, but I'm struggling, can't beat 30% of live performance plank.

[ZOS_ChipHilseberg]

Originally Posted by Fyrakin My figures are astounding, using just a few add-ons that run like a rabbit on steroids on live make PTS choke up after running for a few minutes. I also noticed that collectgarbage("count") is filling very fast (too fast) compared to live. Maybe that's the problem? I'm trying to alter my add-on to run faster on PTS, but I'm struggling, can't beat 30% of live performance plank.

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.

[Fyrakin]

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.

After todays patch /re is back on track, but perfomance while using my own add-on along with some other just by riding a mount forth and back through the map makes performance degrade. collectgarbage("count") indicates much faster growing than live - 29MB just after /re and about 46MB after a few minutes of riding a mount. On live version I can ride a mount for hours without having any issues. I switched most of variables to local, but it doesn't help on PTS. Increasing LUA memory limit has no effect on performance, it still degrades after same amount of time.

Edit: Performance drops are hiccups followed by FPS drops. Using same settings for live and PTS.

[QuadroTony]

cant test current pts because i was suspended for 72 hours will test tomorrow

btw do you know ZOS didnt block your account to login, they just change your password temporary

[Fyrakin]

After some internal tests I was able to pinpoint weak spots.

I have a suspicion that either math.sqrt is working not like on live or normalized coordinate values for wayshrines and player position have more decimal places, what I am seeing is that a simple distance formula sqrt ((x1-x2)^2+(y1-y2)^2) takes a lot more power to complete on pts. This results in signiffican performance loss FPS drops UI lags, etc. Also SetMapToPlayerLocation() works much slower than on live, it is another source of performance loss.

[merlight]

Originally Posted by Fyrakin After some internal tests I was able to pinpoint weak spots. I have a suspicion that either math.sqrt is working not like on live or normalized coordinate values for wayshrines and player position have more decimal places, what I am seeing is that a simple distance formula sqrt ((x1-x2)^2+(y1-y2)^2) takes a lot more power to complete on pts. This results in signiffican performance loss FPS drops UI lags, etc. Also SetMapToPlayerLocation() works much slower than on live, it is another source of performance loss.

Won't fix bad flop performance, but here's a common optimization for distance checks that might help you:

-- instead of
if sqrt((x1-x2)^2 + (y1-y2)^2) < MAX_DIST then ... end
 
-- do
local dx = x1 - x2
local dy = y1 - y2
local dist2 = dx*dx + dy*dy
if dist2 < MAX_DIST2 then ... end
-- MAX_DIST2 = MAX_DIST^2
-- and needs only be computed once if you have fixed MAX_DIST

You don't have to compute sqrt for a distance check, square the threshold instead, it's cheaper. And of course, once you compute the squared distance, memoize it, don't compute it again for another check a few lines below

[Fyrakin]

Originally Posted by merlight Won't fix bad flop performance, but here's a common optimization for distance checks that might help you: -- instead of if sqrt((x1-x2)^2 + (y1-y2)^2) < MAX_DIST then ... end   -- do local dx = x1 - x2 local dy = y1 - y2 local dist2 = dx*dx + dy*dy if dist2 < MAX_DIST2 then ... end -- MAX_DIST2 = MAX_DIST^2 -- and needs only be computed once if you have fixed MAX_DIST You don't have to compute sqrt for a distance check, square the threshold instead, it's cheaper. And of course, once you compute the squared distance, memoize it, don't compute it again for another check a few lines below

I found a way around without a need to scrap the root, but if I run into another performance hindrance I'll have to resort to that. My problem with distance checks is that when player moves all distances change and I have to recalculate all of them to make sure I selected the ones I need.

[merlight]

Originally Posted by Fyrakin I found a way around without a need to scrap the root, but if I run into another performance hindrance I'll have to resort to that. My problem with distance checks is that when player moves all distances change and I have to recalculate all of them to make sure I selected the ones I need.

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