Closed dbaston closed 4 years ago
Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found it was in an excellent condition.
@ocefpaf (or someone else of the maintainers) can you take a look at this?
@dbaston this doesn't seem to have solved it. I just created a fresh environment, ensuring it is now using build he1b5a44_1 instead of he1b5a44_0, and I still see the same slowdown in the example of https://github.com/Toblerity/Shapely/issues/847#issuecomment-593598339
Tested with
conda create -n test0 ipython geos=3.8.0=he1b5a44_0 pygeos
and
conda create -n test1 ipython geos=3.8.0=he1b5a44_1 pygeos
and the example code:
import numpy as np
import pygeos
t = np.arange(1, 10000)
arr = pygeos.points(100000*np.sin(t), 100000*np.sin(4*t))
arr2 = pygeos.buffer(arr, radius=200, quadsegs=32)
union = pygeos.union_all(arr2)
%timeit pygeos.buffer(union, radius=1)
In both cases this is giving around 3 seconds (while with a local build of GEOS master gives around 60ms)
I checked locally the GEOS 3.8.0 tag as well, and then I also get a slowdown. So it seems the "performance fix" was only commited after 3.8.0, and might be a candidate for backporting to 3.8.x (if not yet done)
The GEOS 3.8.x branch is also slow, so opened https://github.com/libgeos/geos/issues/293
@jorisvandenbossche would patching our 3.8.0 build with https://github.com/libgeos/geos/commit/1bf16cdf5a4827b483a1f712e0597ccb243f58cb help? If so I can do that now and we can add a speed test to the feedstock.
I think the plan is to release a 3.8.1 shortly, so would rather try to get it backported on the GEOS side first
OK. Ping me if you need anything on the conda-forge side.
@ocefpaf it will be fixed in 3.8.1
Awesome! We'll check the ABI and re-pin/migrate as needed.
Checklist
0
(if the version changed)conda-smithy
(Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)