Memory profiling
A memory profiling of the parameter-framework has been performed using Valgrind's Massif tool while running the Getting started tutorial. In order to reproduce the results, you should install the samples as well as the Parameter Framework and the sample described below.
It was run under various conditions using a sample client you can find in this commit. Massif can measure both the heap and the stacks but we only measured the heap.
4 phases of the Parameter Framework's lifecycle have been tested:
- Phase 0: Instantiation of the Parameter Framework object (ParameterMgrFullConnector);
- Phase 1: Phase 0 + creation of 2 criteria (one exclusive, one inclusive) with 3 "values" each;
- Phase 2: Phase 1 + actually starting the Parameter Framework (which triggers loading the XML files);
- Phase 3: Phase 2 + calling applyConfigurations()
The cost of criteria has also been tested by benchmarking phase 1 with different number of criteria: in addition of the 2 criteria described above, an exclusive criterion type is created and N criteria are created with that same type.
The results below can be reproduced with:
valgrind --tool=massif --time-unit=B --detailed-freq=1 --max-snapshots=200 pfw-memory-profiling ./ParameterFrameworkConfiguration.xml <phase> <nb of additional criteria>
pfw-memory-profiling is the sample client described at the beginning; --time-unit=B is useful for short-lived programs because the "time" axis increases whenever memory is allocated on the stack or the heap; --time-unit=i. Keep in mind that the horizontal axis is not related to the elapsed time.
The screenshots are obtained with Massif Visualizer.
For each phase, we give the heap cost in KiB because that's massif's unit (reminder: 1KiB == 1024B) and the "extra heap cost" which is the allocation overhead, see the Massif manual. Please note: unfortunately, the vertical axis is in bytes (e.g. 100000B == 97.7KiB).
<phase>=0, <nb of additional criteria>=0
The peak is 15.1KiB + 3.6KiB extra.
<phase>=1, <nb of additional criteria>=0
The peak is at 15.8KiB + 3.8KiB extra.
<phase>=2, <nb of additional criteria>=0
The peak is 97.7KiB + 10.7KiB extra; which is mostly due to XML processing. Then, at a steady state, the memory consumption is 27.5KiB + 7.6KiB extra (this can be known by switching the time unit to "ms" and adding a call to usleep() after starting the Parameter Framework).
Each of the big 4 pikes are the loading of an XML file:
- Top-level configuration
- Class
- Structure
- Settings
This result depends on the contents of the Structure and Settings files and will be the subject of future analysis.
<phase>=3, <nb of additional criteria>=0
The results are almost the same as phase 2.
We can also run phase 1 with an increasing number of additional criteria. The results are summed up in this table:
| additional criteria | memory used |
|---|---|
| 0 | 15.8KiB + 3.8 |
| 1 | 16.1KiB + 3.9 |
| 2 | 16.3KiB + 3.9 |
| 10 | 17.4KiB + 4.0 |
| 20 | 18.7KiB + 4.2 |
This would indicate the the cost of a criterion is roughly 140B and that the cost of n criteria has a space complexity of O(n). This does not include the cost of the criterion type. By subtracting the results of phase 0 to the results of phase 1, We can see that 2 criteria + 2 criteria types cost in total 0.7KiB (=720B).