Speed up memory use reports
Does the matching of frees to allocations and gather of active memory against labels in SWIFT, which speeds things up by a couple of orders of magnitude. The output files are still quite large, but need no further processing, so that is not a big issue. Other better features are that the memory time series is continuous, i.e. maintains value between dumps, so they can be viewed without rebasing. The end summaries are also for all active memory, not just the memory allocated in this step.
Minor changes:
-
struct entryin cache.h changed tostruct sort_entry,entryis a bit generic and clashes with the<search.h>struct of the same name (equally badly named). -
the post-processing scripts are removed as no longer needed and the documentation is updated.
The memory use of the code is large (10% of an EAGLE_50) run and there are a lot of small internal allocations. The latter could be improved with effort, if pooled indices instead of pointers where used.
Fixes #579 (closed)
Merge request reports
Activity
mentioned in issue #579 (closed)
added 485 commits
-
3c79f62e...11300e89 - 483 commits from branch
master - 7302eae3 - Merge remote-tracking branch 'origin/master' into memuse_rnodes
- 726a43c8 - Remove out of date comment
-
3c79f62e...11300e89 - 483 commits from branch
added enhancement label
assigned to @matthieu
When you have a moment (hah) have a look at this. Most of it is orthogonal to SWIFT, so the risk should be very low, the only change to care about is the struct rename (which we do not actually need since I stopped including the header file it clashed with, but it seems like a good idea anyway). @nnrw56 if you are looking the the use of memory by the sorts, this could be useful, but equally it swamps all the other signals, so although you can plot a time series of main memory use, the more interesting numbers are found at the end of the dump, i.e. allocations still active and peak memory use.
@pdraper Cool, thanks, I'll have a look!
mentioned in commit ba842dd6
