Loading...
  OR  Zero-K Name:    Password:   
Title: FFA Pot
Host: CHrankAdminDeinFreund
Game version: Zero-K v1.6.4.0
Engine version: 104.0.1-351-g58d4066
Battle ID: 493848
Started: 6 years ago
Duration: 51 minutes
Players: 5
Bots: False
Mission: False
Rating: Casual
Watch Replay Now
Manual download

Team 1
Chance of victory: 87.6%

CHrankAdminDeinFreund
Team 2
Chance of victory: 0.6%

PLrankKnightOfNee
Team 3
Chance of victory: 0.4%

RUrankplayerO1
Team 4
Chance of victory: 0.9%

DErankTwonki
Team 5
Chance of victory: 10.4%

ATrankATOSTIC

Show winners



Preview
Filter:    Player:  
sort
Had some 10+ sec lagspikes here, when giving commands to many units. Feels like FFA really has some problems.

ATrankATOSTIC said he could hardly play at all.
+0 / -0
I had a look. I did not find or fix any specific regression but I did make a stable with improved LUPS performance, especially for nanospray. A lot of the performance problems in the replay were due to unsynced luarules, which is where nanospray lives. Perhaps there is no regression and we are simply seeing the effects of Conch meta and the associated nanospray spam.
+1 / -0
quote:
Perhaps there is no regression and we are simply seeing the effects of Conch meta and the associated nanospray spam.

At least for my issue, i don't think this is likely. I watched a game yesterday which was a 4v4 on Intersection yesterday. I was not able to catch up. Zero conches.

More importantly, LUPS nanosprays have not changed for years. Catch-up speed did. I had zero perf issues in the ffa where i made a Starlight on Throne Acidic out of Caretaker income.

I guess it just needs benchmarks to be run on affected systems; i'll try to figure this out on Thursday.
+0 / -0


6 years ago
I found and bisected a big performance regression in the engine: https://springrts.com/mantis/view.php?id=5951.
+2 / -0


6 years ago
I've bisected the issue to a single commit which increased the frequency of garbage collection.
+1 / -0
There has been a change, I am not entirely sure to what. I think it decreases the amount of garbage collection per garbage updates if there is not too much of it but does not change the frequency. I think the original change was an increase in GC frequency from once a second to 30 times a second.

I've applied the engine, do some FFA and try it out. Perhaps my tests are only on unimportant cases.

Much more information is in the ticket, if you want to wade in: https://springrts.com/mantis/view.php?id=5951
+1 / -0

6 years ago
quote:
I think the original change was an increase in GC frequency from once a second to 30 times a second.

No, it was a change from 30/second to 1/gameframe (ie. also 30 times a second unless gamespeed is not x1, such as catching up).
+0 / -0