-
Notifications
You must be signed in to change notification settings - Fork 781
Improve performance of wrap method #5226
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
base: develop
Are you sure you want to change the base?
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #5226 +/- ##
===========================================
- Coverage 93.83% 93.82% -0.01%
===========================================
Files 180 180
Lines 22475 22473 -2
Branches 3190 3189 -1
===========================================
- Hits 21090 21086 -4
- Misses 923 924 +1
- Partials 462 463 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
orbeckst
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good but I didn't have time to dive into it. Can you confirm that it produces the same results? I know that the tests covered it but did you look if the tests for it actually likely to find any disagreement?
|
The tests are already quite comprehensive. I only noticed that the tests do not check whether it also works with non-contiguous compound indexes. Since the current code and the PR use fancy-indexing, I added such a test. |
Changes made in this Pull Request:
The method was significantly slower than expected when wrapping compounds (residues, fragments, molecules, segments). See the corresponding issue on the MAICoS repo.
It just never got the same performance increases as for example
unwrap. I considered using the_split_by_compound_indicesapproach fromunwrap, but that is actually not needed for wrapping. Simply calculating the shifts and applying them in one go yields an enormous speed up. Most the performance penalty actually came from thenp.wheredone in each loop I believe.Here is a scaling plot comparing the speeds:
LLM / AI generated code disclosure
LLMs or other AI-powered tools (beyond simple IDE use cases) were used in this contribution: no
PR Checklist
package/CHANGELOGfile updated?package/AUTHORS? (If it is not, add it!)Developers Certificate of Origin
I certify that I can submit this code contribution as described in the Developer Certificate of Origin, under the MDAnalysis LICENSE.