deprecate direct field access for geo-types #818
Closed
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.
CHANGES.md
if knowledge of this change could be valuable to users.FIXES #816
deprecate direct field access for geo-types, plus some other methods to help migrate from direct field access.
This is intended to be a non-breaking change for now, to give people an upgrade window. In an upcoming breaking release of geo-types we'll drop pub field access altogether.
This is in pursuit of adding support for 3D/4D geometries. When we do that, we'll leverage generics in a way that is intended to avoid runtime cost for our mostly 2D user base. See #5 for more.
This commit includes a bunch of new methods that correspond to the deprecated
field access. See geo-types/CHANGES.md for a summary.
#[inline]
hints were added to maintain performance (it's actually improved insome places!)
geo was updated to address all the deprecations.
review
This PR is really big. I think the changes to really scrutinize are in geo-types. Applying it all to
geo
is large but very rote.I think there's potential to add further methods to make code that uses geo-types a little nicer, but I tried to strike the right balance between minimizing this diff while not committing egregiously worse code that would immediately churn in a followup pr.
docs
A lot of the work was getting the docs right. You can build them yourself, or check them here: doc.tar.gz
(We should have a CI action that uploads a web accessible preview of the docs... I'll create an issue)
perf
Cargo bench is mostly unchanged, but surprisingly got a bit better for a couple things - in particular:
I was curious why this would be. It seems like most of the difference is attributable to inlining the
Rect::new
constructor. Which is pretty wild, because we're not actually givingRect::new
any additional inline hints. It's plausible the the new inline hints on Coord are having percolating effects.I don't have a great way to share that analysis, but here's a screenshot showing the "bottom up" view of rstar::bulk_load while profiling the simplify benches:
Before, on the left, within bulk_load we were spending about 25% of the time in Rect::new. After, it goes away completely.
Heres the entire criterion output if you want a closer look:
criterion.tar.gz
output of `cargo bench --bench "*" -- --baseline main`