|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006080||Spring engine||General||public||2018-11-15 04:50||2018-11-26 18:00|
|Product Version||104.0 +git|
|Target Version||Fixed in Version|
|Summary||0006080: Performance regression with varying GC load|
|Description||I bisected a performance regression to between 104.0.1-409-g07c2800 and 104.0.1-483-g30d8543. The regression is due to the commit (https://github.com/spring/spring/commit/0e61b6fb367f1807022a00c3ade633f283afafb1) which varys GC frequency based on load.|
As far as I can tell, setting LuaGarbageCollectionMemLoadMult = 100 (see https://github.com/spring/spring/commit/8a287cf9ec65d0d3eccd44dd7a541d393be51473) effectively reverts the varied GC frequency commit. I ran a benchmark on 287, 889, and 889 with LuaGarbageCollectionMemLoadMult = 100. The benchmark consists of many units shooting the ground for 40 seconds (see the attached image) so sync between versions is not too much of a worry.
I measure dt as reported by Widget:Update and use a timer to measure the gaps between Widget:GameFrame. Engine 287 and 889 with LuaGarbageCollectionMemLoadMult = 100 behaved fairly similarly. 889 with no changes has a much higher variance in dt and has an average gameFrame fps of 10, compared to 15 for the other two test cases.
Technically, no change is required because LuaGarbageCollectionMemLoadMult = 100 fixes the issue. However, Spring should have good defaults so the code could be removed or 100 could be set as the default. Also, I think it is interesting to note that running the GC consistently but more frequently leads to better overall performance than running it less frequently and randomly. More investigation of GC running frequency could be undertaken. I could run more benchmarks if more parameters are exposed to springsettings.
|Tags||No tags attached.|
|Checked infolog.txt for Errors|
Last edited: 2018-11-16 20:53
This is an unforeseen result, but may not generalize to other games so I'll add some more knobs before changing the default multiplier. It will depend on how much garbage Lua code actually produces (a lot in ZK's case) as well as on the gc internals.
Also note that consistent more frequent calls (one per simframe as opposed to *at most* 30 per second) did cause a regression. Retrying luagccontrol=0 with loadmult=100 would be interesting.
Fix 4d08e7f058042cf0022608ab5dd58954a1551dec committed to develop branch: fix 0006080
add knobs, repo: spring changeset id: 11168
Fix 82a205f31a4ce8dc71925a06cd5cd87edc6125bc committed to maintenance branch: fix 0006080
add knobs, repo: spring changeset id: 11169
|2018-11-15 04:50||Google_Frog||New Issue|
|2018-11-15 04:50||Google_Frog||File Added: benchmarkImage.jpg|
|2018-11-15 04:50||Google_Frog||File Added: benchmarkFrequencyBins.jpg|
|2018-11-15 04:51||Google_Frog||File Added: loadMult.ods|
|2018-11-16 20:50||Kloot||Note Added: 0019556|
|2018-11-16 20:53||Kloot||Note Edited: 0019556||View Revisions|
|2018-11-26 18:00||Kloot||Changeset attached||=> spring develop 4d08e7f0|
|2018-11-26 18:00||Kloot||Note Added: 0019580|
|2018-11-26 18:00||Kloot||Assigned To||=> Kloot|
|2018-11-26 18:00||Kloot||Status||new => resolved|
|2018-11-26 18:00||Kloot||Resolution||open => fixed|
|2018-11-26 18:00||Kloot||Changeset attached||=> spring maintenance 82a205f3|
|2018-11-26 18:00||Kloot||Note Added: 0019581|