Lock file updates and libnetcdf regression notification
#6747
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
trexfeathers
added
the
benchmark_this
This was referenced Oct 14, 2025
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6747 +/- ##
=======================================
Coverage 90.29% 90.29%
=======================================
Files 91 91
Lines 24475 24475
Branches 4571 4571
=======================================
Hits 22100 22100
Misses 1607 1607
Partials 768 768 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
⏱️ Performance Benchmark Report: c90bd50Performance shiftsFull benchmark resultsGenerated by GHA run |
⏱️ Performance Benchmark Report: c90bd50Performance shiftsFull benchmark resultsGenerated by GHA run |
stephenworsley
approved these changes
Oct 15, 2025
There was a problem hiding this comment.
As agreed, this makes sense as just a documantation change for the time being. It does seem a little odd to put this in the whatsnew when it doesn't refer to an actual change in the code base but, on reflection, I can't think of anywhere more suitable to put this. We essentially want to highlight a performance change due to a particular update in a dependancy, but it doesn't seem major enough to mention in the load docstrings (though I'd like to double check your opinion on this before merging). In the whatsnew, this is at least timestamped to a time when this version update is relevant.
An interesting thought. I agree that this isn't major enough. Indeed if a case were major enough for that I would probably be considering hack fixes within Iris. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #6714 - this is the same change but includes an important What's New announcement.
Following from this comment: #6714 (comment)
Test failures
Some tricky Conda resolution had forced us onto a PyVista version which was incompatible with recent VTK releases:
0.44.1=pyhd8ed1ab_0. This version was not intended for use, and should be expected to cause test failures; it was superceded by a newer build number which included a VTK<9.4pin:0.44.1=pyhd8ed1ab_1.Within the last week a new version of PyVista was released, which included updated pins, making the Conda resolution simpler - can now use VTK version 9.5 - and allowing a passing suite of tests.
It should be noted that we still have a similar situation with the environment using an old build of GeoVista, which again has inappropriate pins and is not expected to be fully functional:
0.5.3=pyhd8ed1ab_1, when it should be0.5.3=pyhd8ed1ab_2. Unfortunately we cannot specify build numbers in greater-than dependency pins, and GeoVista is functioning well enough for our tests so I propose to leave as-is.Performance regressions
I did a thorough investigation and proof-of-concept for how we might avoid repeated open-and-close of NetCDF files within Iris, which would mitigate the performance regressions. While this yielded performance improvements for larger files (#6735 (comment)), I was also finding concurrency issues in a number of corner cases. I did not have confidence that I could create a solution which was:
Given the above, and since this is at-heart a problem in
libnetcdf, I am proposing to instead:nc_openwith version 4.9.3 Unidata/netcdf-c#3183