iox-#1030 Speed up posh tests

[elBoberido]

Pre-Review Checklist for the PR Author

1. Code follows the coding style of CONTRIBUTING.md
2. Tests follow the best practice for testing
3. Changelog updated in the unreleased section including API breaking changes
4. Branch follows the naming format (iox-123-this-is-a-branch)
5. Commits messages are according to this guideline
   • Commit messages have the issue ID (iox-#123 commit text)
   • Commit author matches Eclipse Contributor Agreement (and ECA is signed)
6. Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
7. Relevant issues are linked
8. Add sensible notes for the reviewer
9. All checks have passed (except task-list-completed)
10. All touched (C/C++) source code files from iceoryx_hoofs are added to ./clang-tidy-diff-scans.txt
11. Assign PR to reviewer

Notes for Reviewer

This PR reduces the test time by more than two minutes. Some CI jobs are now even four minutes faster compared to the latest master build.

This is also getting a bit out of hand since the faster shutdown of RouDi uncovered some issues in the examples which happened previously only sporadically.

Checklist for the PR Reviewer

• Commits are properly organized and messages are according to the guideline
• Code according to our coding style and naming conventions
• Unit tests have been written for new behavior
• Public API changes are documented via doxygen
• Copyright owner are updated in the changed files
• All touched (C/C++) source code files from iceoryx_hoofs have been added to ./clang-tidy-diff-scans.txt
• PR title describes the changes

Post-review Checklist for the PR Author

1. All open points are addressed and tracked via issues

References

• Closes Speed up posh tests #1030
• Closes ServiceDiscovery uses instrospection MemPools #1359

[elBoberido]

Oh boy, I remember the bikeshedding regarding the right (i.e. fastest) data structure for the ServiceRegistry well enough but it seems after the implementation nobody bothered to look at the slow tests with flamegraph to discover that there is something an order of magnitude slower than the most naive data structure one can use. This is a prime example why one should measure first and then optimize the bottleneck.

[codecov]

Codecov Report

Merging #2020 (e0e0835) into master (c5d1340) will decrease coverage by 0.04%.
Report is 4 commits behind head on master.
The diff coverage is 78.40%.

❗ Current head e0e0835 differs from pull request most recent head 86d539b. Consider uploading reports for the commit 86d539b to get more accurate results

@@            Coverage Diff             @@
##           master    #2020      +/-   ##
==========================================
- Coverage   74.27%   74.24%   -0.04%     
==========================================
  Files         413      413              
  Lines       16055    16150      +95     
  Branches     2246     2257      +11     
==========================================
+ Hits        11925    11990      +65     
- Misses       3411     3434      +23     
- Partials      719      726       +7     

Flag	Coverage Δ
unittests	74.03% <78.40%> (-0.04%)	⬇️
unittests_timing	15.16% <2.27%> (-0.09%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed	Coverage Δ
...clude/iceoryx_posh/internal/roudi/port_manager.hpp	100.00% <ø> (ø)
...de/iceoryx_posh/internal/roudi/process_manager.hpp	100.00% <ø> (ø)
...iceoryx_posh/roudi/memory/default_roudi_memory.hpp	100.00% <ø> (ø)
...posh/roudi/memory/iceoryx_roudi_memory_manager.hpp	22.22% <ø> (ø)
...eoryx_posh/roudi/memory/roudi_memory_interface.hpp	100.00% <ø> (ø)
...iceoryx_posh/roudi/memory/roudi_memory_manager.hpp	100.00% <ø> (ø)
...oryx_posh/include/iceoryx_posh/roudi/roudi_app.hpp	100.00% <ø> (ø)
...clude/iceoryx_posh/roudi/roudi_cmd_line_parser.hpp	100.00% <ø> (ø)
...roudi/roudi_cmd_line_parser_config_file_option.hpp	100.00% <ø> (ø)
...osh/source/roudi/application/iceoryx_roudi_app.cpp	33.33% <0.00%> (ø)
... and 15 more

... and 4 files with indirect coverage changes

📢 Have feedback on the report? Share it here.

[FerdinandSpitzschnueffler]

I'm not finished with the review yet, will continue later.

[elBoberido]

I think I found the reason (or at least one) for sporadic failures of the integration tests. It seems there was a race between launch_testing and RouDi trying to terminate the applications. I fixed the issue at the cost of additional 200 lines to review.

[mossmaurice]

@elBoberido LGTM, thanks for the PR!

One wish: Could we please move the C binding move to another repository before the v3.0 C release like we did with the other optional bindings? This PR would have been much smaller and I prefer reviewing things step-by-step. Also, like with the other bindings we only have to update them if there is a need and only once after the release.

Regarding ROS 2: IMO this should stay on v2.0.3 even after v3.0 was released, so we don't have to implement any changes in Cyclone DDS.

Shall I create an issue for that?

cc @dkroenke

[elBoberido]

@mossmaurice I would keep the bindings for the v3 release and only move them afterwards. In general it does not cost us much and especially if we agree on the reduced scope of the v3 release it would not be much extra work. It might even be less work than to remove them. At least from some comments in some issues I have the feeling some people are using Cyclone DDS with the latest iceoryx master and for them it would be nice to have the bindings in the v3 release. Doing the move right after the v3 release would also result in a better transition path for these users.

cc @dkroenke

[mossmaurice]

I would keep the bindings for the v3 release and only move them afterwards. In general it does not cost us much and especially if we agree on the reduced scope of the v3 release it would not be much extra work. It might even be less work than to remove them. At least from some comments in some issues I have the feeling some people are using Cyclone DDS with the latest iceoryx master and for them it would be nice to have the bindings in the v3 release. Doing the move right after the v3 release would also result in a better transition path for these users.

@elBoberido That makes sense to me.

Could please still create the issue for the move to a separate repository and assign it to the v4.0 project? Thanks 🙏

[elBoberido]

@mossmaurice done with #2030