Repository navigation
Move spline calculation outside the for loop, reducing runtime by 25%. - #1037
hugobuddel wants to merge 1 commit into
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1037 +/- ##
==========================================
- Coverage 74.87% 74.85% -0.02%
==========================================
Files 70 70
Lines 9003 9005 +2
==========================================
Hits 6741 6741
- Misses 2262 2264 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
332a594 to
7b0eb4e
Compare
|
Drafted, because I'm not sure this is the right approach. We could also do #1038, which is even better, and makes this redundant, but is perhaps too complex. What do you think? |
|
As discussed in #1038 (comment) it would be better to use an explicit interpolation, which would make this P.R. kinda redundant. But in the meantime, I think we can still merge this, as this change is not too invasive. But I'm also fine with closing this. I'll unwip it. |
|
I'm slightly worried about the "0 % patch coverage" here. While coverage itself has limited utility as a measure, if the affected code is not covered by anything, that's a bit concerning... I also realize it's maybe hard to test the LMS, but the "basic_instrument" should have an IFU mode. |
oczoske
left a comment
There was a problem hiding this comment.
This is quite harmless and only repairs a stupid loop nesting. The additional memory requirement for keeping the list spatial_interps should be manageable. Explicit interpolation can be implemented once this PR is merged, modifying l.120 (new) instead of l.136 (old).
I've timed this with a small script:
and that goes from about 160 seconds to 125 seconds.