Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The ContactResultsMap results in a significant amount of heap allocations during motion planning. #863

Open
Levi-Armstrong opened this issue Mar 14, 2023 · 3 comments

Comments

@Levi-Armstrong
Copy link
Contributor

This data structure should be updated to leverage Pool library to avoid this. Links to documentation of available options:

Boost Pool Library
Boost Pool Library Examples

@Levi-Armstrong
Copy link
Contributor Author

@Levi-Armstrong Levi-Armstrong changed the title The ContactResultsMap results in a significant amount of heap allocation during motion planning. The ContactResultsMap results in a significant amount of heap allocations during motion planning. Mar 15, 2023
@Levi-Armstrong
Copy link
Contributor Author

Levi-Armstrong commented Mar 15, 2023

Here is PR #864 where I started leveraging std::pmr but not sure if it is being used correctly and needs further testing.

@Levi-Armstrong
Copy link
Contributor Author

Levi-Armstrong commented Mar 18, 2023

After watching a few cppcon presentation on this functionality it is more involved that I thought when using std::pmr if you are storing a custom class/struct. Each of the structs data members would need to use pmr types like string and std::array. On the final slide of one of the presentation they stated that usually an object pool or custom struct would be sufficient without the complexity of std::pmr. I agree and think a custom class can be created to store an internal map and control how things are cleared to reduce multiple allocations during collision checking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant