-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Avoid using Bbox machinery in Path.get_extents; special case polylines. #17995
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
Conversation
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.
Looks good to me. Any reason bbox.update_from_data_xy
is so slow?
Because it constructs general path objects and then iterates over it using overly general mechanisms, I guess. |
update_from_data_xy is much slower than needed; we can use plain numpy instead. For polylines, we can completely skip the bezier handling for even more speedup.
As a performance regression fix, should this be backported to 3.3.1? |
I think the regression has been there since 3.0.0, so not urgent, unless there is something more than the tight_bbox PR that added to the slowdown. |
Further discussion on #17974 says this was introduced in 3.3.0, so maybe we should backport this? |
@meeseeksdev backport to v3.3.x |
…extents; special case polylines.
…995-on-v3.3.x Backport PR #17995 on branch v3.3.x (Avoid using Bbox machinery in Path.get_extents; special case polylines.)
update_from_data_xy is much slower than needed; we can use plain numpy
instead. (This speeds up #17974 another ~30-40% on top of #17994.)
For polylines, we can completely skip the bezier handling for even more
speedup. (This fixes the performance regression.)
PR Summary
PR Checklist