You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See discussion at #983 (comment), repeating my summary here:
In general: yes, there is a slowdown for methods/properties of scalar Geometry objects.
For some things (like the constructors of the different geometry classes), we can optimize this by spending some effort in having an efficient single-geometry version (this can probably be done in the class constructor itself, eg by using pygeos.lib.points instead of pygeos.points).
But for the bulk of the ufuncs (the spatial predicates, operations, etc., i.e. those that directly wrap one of the GEOS<..op..>_r functions), this is the consequence of having general ufunc (array-aware) functions. This ufunc machinery will always have some overhead, and for single geometries this overhead can be noticeable (and seems to be larger as the benefit from not using ctypes).
So I think that generally speaking we can live with a small additional overhead (given that the vectorized operations will be much faster), but we should of course still fix the slowdown where easily possible.
The text was updated successfully, but these errors were encountered:
See discussion at #983 (comment), repeating my summary here:
In general: yes, there is a slowdown for methods/properties of scalar Geometry objects.
For some things (like the constructors of the different geometry classes), we can optimize this by spending some effort in having an efficient single-geometry version (this can probably be done in the class constructor itself, eg by using
pygeos.lib.points
instead ofpygeos.points
).But for the bulk of the ufuncs (the spatial predicates, operations, etc., i.e. those that directly wrap one of the
GEOS<..op..>_r
functions), this is the consequence of having general ufunc (array-aware) functions. This ufunc machinery will always have some overhead, and for single geometries this overhead can be noticeable (and seems to be larger as the benefit from not using ctypes).So I think that generally speaking we can live with a small additional overhead (given that the vectorized operations will be much faster), but we should of course still fix the slowdown where easily possible.
The text was updated successfully, but these errors were encountered: