2018-12-12 06:29 CET

View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0006080Spring engineGeneralpublic2018-11-26 18:00
Assigned ToKloot 
Product Version104.0 +git 
Target VersionFixed in Version 
Summary0006080: Performance regression with varying GC load
DescriptionI 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.
TagsNo tags attached.
Attached Files




Kloot (developer)

Last edited: 2018-11-16 20:53

View 2 revisions

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.


Kloot (developer)

Fix 4d08e7f058042cf0022608ab5dd58954a1551dec committed to develop branch: fix 0006080
add knobs, repo: spring changeset id: 11168


Kloot (developer)

Fix 82a205f31a4ce8dc71925a06cd5cd87edc6125bc committed to maintenance branch: fix 0006080
add knobs, repo: spring changeset id: 11169

+Related Changesets

-Issue History
Date Modified Username Field Change
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
+Issue History