17 Timing framework

[reneSchm]

Changes and Information

Please briefly list the changes (main added features, changed items, or corrected bugs) made:

• Add a framework with an thread safe Timer.
• Used via ScopedTimer, it should guarantee that the timers use the correct thread.
• Timers are aggregated via TimeRegistrar, and can be evaluated.

If need be, add additional information and what the reviewer should look out for in particular:

• What is missing from the framework:
  • A way to disable timers. Disabling during runtime is intentionally not implemented, as it creates some overhead for start/stop methods. A compile time disable could be implemented using e.g. the Tag.
  • CPU timers. The current impl. only supports wall clock (std::steady_clock or omp_get_wtime).
  • Instancing the same Timer multiple times. This is a deliberate trade-off, as using static thread_local Timers enables thread safety and using the CT map.
• Please check the naming. In particular, an alternative for ScopedTimer would be AutoTimer, as the prefix "auto" is somewhat commonly used to describe classes that use their lifetime as switch on/off (e.g. auto_mutex). Also the TimerRegistrar could perhaps use a new name.

Merge Request - Guideline Checklist

Please check our git workflow. Use the draft feature if the Pull Request is not yet ready to review.

Checks by code author

• [ ] Every addressed issue is linked (use the "Closes #ISSUE" keyword below)
• [ ] New code adheres to coding guidelines
• [ ] No large data files have been added (files should in sum not exceed 100 KB, avoid PDFs, Word docs, etc.)
• [ ] Tests are added for new functionality and a local test run was successful (with and without OpenMP)
• [ ] Appropriate documentation for new functionality has been added (Doxygen in the code and Markdown files if necessary)
• [ ] Proper attention to licenses, especially no new third-party software with conflicting license has been added
• [ ] (For ABM development) Checked benchmark results and ran and posted a local test above from before and after development to ensure performance is monitored.

Checks by code reviewer(s)

• [ ] Corresponding issue(s) is/are linked and addressed
• [ ] Code is clean of development artifacts (no deactivated or commented code lines, no debugging printouts, etc.)
• [ ] Appropriate unit tests have been added, CI passes, code coverage and performance is acceptable (did not decrease)
• [ ] No large data files added in the whole history of commits(files should in sum not exceed 100 KB, avoid PDFs, Word docs, etc.)
• [ ] On merge, add 2-5 lines with the changes (main added features, changed items, or corrected bugs) to the merge-commit-message. This can be taken from the briefly-list-the-changes above (best case) or the separate commit messages (worst case).

Closes #17