Add profiling to CI workflow

[tztsai]

Description

Updated the CI workflow so that when there is a pull_request event (created, ready for review, merged, etc.), it will automatically run profiling using the LFS dataset. Subsequently it will report the profiling results in a CSV file, generate the call graph and some performance benchmark plots in the profiling/ folder. These generated files will be added to a new Git commit and pushed to the current branch right before this branch is going to be merged. However, the last feature requires that the branch to merge into must enable the "Require merge queue" setting in the branch protection rules (see https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue).

Fixes #142, #152

Type of change

• [x] New feature (non-breaking change which adds functionality)
• [ ] Optimization (back-end change that speeds up the code)
• [ ] Bug fix (non-breaking change which fixes an issue)

Key checklist

• [x] Make sure you've run the pre-commit checks: $ pre-commit run -a
• [x] All tests pass: $ poetry run pytest

Further checks

• [x] Code is commented, particularly in hard-to-understand areas
• [x] Tests added that prove fix is effective or that feature works

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (02a8ab8) 94.09% compared to head (80bfde6) 93.38%.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## develop #156 +/- ## =========================================== - Coverage 94.09% 93.38% -0.71% =========================================== Files 21 21 Lines 1134 1134 =========================================== - Hits 1067 1059 -8 - Misses 67 75 +8 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[tztsai]

This looks good. I am not sure that long-term we want the graphical profiling outputs in the repository. Rather, I'd expect that it is enough to describe in the documentation how to get them. But for now I am happy to have them included as latest profiling results, as long as they are overwritten (and we don't accumulate pngs).

Thanks! I implemented the feature of generating graphical profiling outputs because it was one of the tasks specified in #141, i.e. "automate call graph creation". Therefore I imagined it was your intention to automatically create visualization of the profiling results in the CI workflow. Maybe I misunderstood.

[davidorme]

I am not sure that long-term we want the graphical profiling outputs in the repository. Rather, I'd expect that it is enough to describe in the documentation how to get them

@MarionBWeinzierl and @tztsai - slow to reply to this, but in the longer term I think the generation of these plots should move into the documentation. They can be dynamically generated when the HTML docs are built and so the plots there could show tagged builds and develop.