Problem: Memory Management Could be Better Designed #86
Description
Problem Description
The current memory management strategy within ERIN is quite ad hoc and relies entirely upon the std::vector memory characteristics. Although we attempt to reserve vector space when we know the counts, we believe it would be good to investigate how alternate memory management strategies could affect the performance.
In particular, we think that a single pre-allocated memory arena which includes a per-time-step "scratch" area might be a great way to reduce multiple potential behind-the-scenes mallocs and reallocs.
Together with this item, I would like to suggest exploring the following:
- try running existing examples with an overallocated single memory arena large enough for all simulation memory needs and time that to prove that this will even make a difference
- potentially couple this with more clever examination of the TOML input file: for example, should be able to scan the file to count the number of different items that will be coming in along with their types to know exactly how much memory we'll actually need for simulation. Other than scratch memory (i.e., temporarily allocated collections), the only variable memory we have is the number of events per scenario occurrence simulation. I believe that most everything else can be pre-calculated for memory requirements after the toml file is read
- note: if this looks lucrative, we could also potentially examine changes to the TOML parser and TOML input file format to make determination of the counts and types of "objects" (components, distributions, scenarios, etc) easier to determine. Also, the TOML parser itself is a 3rd party library and we may not have access to change its memory management -- if there were truly a benefit, we could even examine the TOML parser itself as what we need to do is far less sophisticated than what the current 3rd party library does.