|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006122||Spring engine||General||public||2019-01-25 16:40||2019-01-29 00:11|
|Target Version||Fixed in Version||104.0 +git|
|Summary||0006122: FeatureDrawer accepts a huge amount of features (consuming a lot of RAM)|
|Description||There is a critical difference between the implementation of UnitDrawer and Feature Drawer. Former has 2 ModelRenderContainer arrays, with 4 elements each one (see rts/Rendering/UnitDrawer.h:277), while latter has a vector with one RdrContProxy per map square (see rts/Rendering/FeatureDrawer.cpp:170), and inside each RdrContProxy it has a single ModelRenderContainer array of 4 elements (see rts/Rendering/FeatureDrawer.h:109).|
The problem is that ModelRenderContainer has 2 arrays of MAX_MODEL_OBJECTS=2048 objects.
Indeed, while just MAX_MODEL_OBJECTS units are accepted for the whole game, MAX_MODEL_OBJECTS features are accepted per map square, leading to a huge number of features accepted, and huge amount of memory consumed regardless whether such features exists or not.
|Steps To Reproduce||* Compile spring-104.maintenance in debug mode|
* Launch with valgrind:
valgrind --tool=massif $HOME/.spring/engine/104-maintenance/bin/spring $HOME/.springlobby/script.txt
* Press Ctrl+C, and patiently wait to run everything.
* Visualize the output file with massif-visualizer (where PID is the pid of the process ran):
|Additional Information||It is sometimes the most RAM consuming factor. ~336MB in a 32x16 map|
|Tags||No tags attached.|
|this indeed isn't great, ModelRenderContainer may need to go back to being a sparse map.|
|fixed in 974+ (maintenance)|
|2019-01-25 16:40||Sanguinario_Joe||New Issue|
|2019-01-25 20:57||Kloot||Note Added: 0019690|
|2019-01-29 00:11||Kloot||Assigned To||=> Kloot|
|2019-01-29 00:11||Kloot||Status||new => resolved|
|2019-01-29 00:11||Kloot||Resolution||open => fixed|
|2019-01-29 00:11||Kloot||Fixed in Version||=> 104.0 +git|
|2019-01-29 00:11||Kloot||Note Added: 0019697|