2024-03-29 16:37 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0006124Spring engineGeneralpublic2019-02-21 12:30
ReporterSanguinario_Joe 
Assigned ToKloot 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version104.0 +git 
Target VersionFixed in Version 
Summary0006124: Better using directly a vector for BlockingMapCell?
DescriptionIn rts/Sim/Misc/GroundBlockingObjectMap.h a custom ArrayVector class is used to define BlockingMapCell. Those are stored in BlockingMap vector, with "map squares" number of elements.

ArrayVector is a smart combination of array, to get some fast elements preallocated, and vector, to can add more elements beyond the initially allocated memory. However, I would say it is failing.

Since an ArrayVector (with 8 preallocated objects in the array) is stored per map square, usually it takes way more mem (192MB in my last test) than the stack allowed, so it is actually stored as heap mem, boiling down almost all the preformance advantages of this array+vec combination. Right? In fact, it is maybe slower since, depending on the number of elements in the map square, it should make some tasks twice.

The problem is that this non-negligible memory is allocated even for the empty map squares.

I'm indeed not sure that using directly a vector is more convenient, so I ask for the opinion of the spring gods :-)
Steps To Reproduce* Compile spring-104 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 get the sim finished.
* Visualize the output file with massif-visualizer (where PID is the pid of the process ran):
    massif-visualizer massif.out.PID
Additional Information192MB consumed in a 32x16 map
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0019694

Kloot (developer)

Last edited: 2019-01-28 11:41

View 2 revisions

> Right?

no.

it is true that the array parts of each cell are stored on the heap within the memory block held by groundBlockingMap. however it is not true this makes the common case (#cell <= 8) slower, since using a vector<vector<>> would always cause two cache misses per lookup instead of one.

these issues will be less relevant once the 32-bit engine builds are discontinued.

~0019755

Kloot (developer)

Fix 1a28dfabe7898708d8ebcb5319c8db7dc1cd1cda committed to develop branch: fix 0006124
BOBW, S=8 overwhelmingly serves the common case, repo: spring changeset id: 11437
+Notes

-Issue History
Date Modified Username Field Change
2019-01-28 09:23 Sanguinario_Joe New Issue
2019-01-28 11:39 Kloot Note Added: 0019694
2019-01-28 11:39 Kloot Status new => closed
2019-01-28 11:39 Kloot Resolution open => no change required
2019-01-28 11:41 Kloot Note Edited: 0019694 View Revisions
2019-02-21 12:29 Kloot Changeset attached => spring develop 1a28dfab
2019-02-21 12:30 Kloot Note Added: 0019755
2019-02-21 12:30 Kloot Assigned To => Kloot
2019-02-21 12:30 Kloot Status closed => resolved
2019-02-21 12:30 Kloot Resolution no change required => fixed
+Issue History