View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
---|---|---|---|---|---|---|---|---|---|
0006124 | Spring engine | General | public | 2019-01-28 09:23 | 2019-02-21 12:30 | ||||
Reporter | Sanguinario_Joe | ||||||||
Assigned To | Kloot | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | resolved | Resolution | fixed | ||||||
Product Version | 104.0 +git | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0006124: Better using directly a vector for BlockingMapCell? | ||||||||
Description | In 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 Information | 192MB consumed in a 32x16 map | ||||||||
Tags | No tags attached. | ||||||||
Checked infolog.txt for Errors | |||||||||
Attached Files |
|
Notes | |
Kloot (developer) 2019-01-28 11:39 Last edited: 2019-01-28 11:41 |
> 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. |
Kloot (developer) 2019-02-21 12:30 |
Fix 1a28dfabe7898708d8ebcb5319c8db7dc1cd1cda committed to develop branch: fix 0006124 BOBW, S=8 overwhelmingly serves the common case, repo: spring changeset id: 11437 |
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 |