Thanks to visit codestin.com
Credit goes to github.com

Skip to content

PERF: optimize coordinate access for scalar Point #2035

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.

Sign up for GitHub

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

Jump to bottom
Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

PERF: optimize coordinate access for scalar Point #2035

wants to merge 1 commit into from
+19 −1

Conversation

jorisvandenbossche
Copy link
Member

@jorisvandenbossche jorisvandenbossche commented Apr 12, 2024 •
edited
Loading

Illustration of what it would entail to optimize specifically the Point.x et al attributes for scalar points.

In [1]: import shapely

In [2]: p = shapely.Point(12, 34)

In [3]: %timeit p.x
3.15 µs ± 3.46 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)    # <-- main
236 ns ± 0.164 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)  # <-- PR

The reason this is so much faster is mostly from avoiding the ufunc machinery overhead.

While this is relatively little code for just those x/y/z attributes, the question is of course then "could we also speed up this other attribute .. ?", and we definitely don't want to end up reimplementing all ufuncs for scalar geometries.

@jorisvandenbossche jorisvandenbossche mentioned this pull request Apr 12, 2024
Open
@coveralls
Copy link

Pull Request Test Coverage Report for Build 8667674559

Details

  • 2 of 2 (100.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.3%) to 88.126%
Totals Coverage Status
Change from base Build 8388286001: 0.3%
Covered Lines: 2620
Relevant Lines: 2973
💛 - Coveralls

@theroggy
Copy link
Member

theroggy commented Jul 25, 2024 •
edited
Loading

While this is relatively little code for just those x/y/z attributes, the question is of course then "could we also speed up this other attribute .. ?", and we definitely don't want to end up reimplementing all ufuncs for scalar geometries.

I definitely understand this...

Then again, there are cases where a vectorized approach is not feasable, e.g. when implementing more complicated algorithms using many basic spatial operations on a single geometry. If a shortcut that bypasses the ufunc machinery if the input is a single element would give a big performance difference for some operations...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@jorisvandenbossche @coveralls @theroggy