GEOSBuildArea performance degradation

[strk]

The performance of GEOSBuildArea degraded from 3.8 to current main.

Passing a set of 9295 noded linestrings to the function result in a 359909 vertices polygon but while GEOS-3.8 can come to the solution within 2 seconds, GEOS-main ( as of 9af19e8 ) takes over 4 seconds.

Logs:

3.8:

00.032078 psql:run.sql:13: DEBUG:  [../../liblwgeom/lwgeom_topo.c:lwt_GetFaceGeometry:2834] lwt_GetFaceGeometry: lwt_be_getEdgeByFace returned 9295 edges
00.037603 psql:run.sql:13: NOTICE:  Calling GEOSBuildArea
01.939422 psql:run.sql:13: NOTICE:  GEOSBuildArea returned
01.946364 psql:run.sql:13: DEBUG:  [../../liblwgeom/lwgeom_topo.c:lwt_ChangeEdgeGeom:3499] lwt_ChangeEdgeGeom: lwt_GetFaceGeometry returned a polygon with 359909 vertices         

main:

00.049306 psql:run.sql:13: DEBUG:  [../../liblwgeom/lwgeom_topo.c:lwt_GetFaceGeometry:2834] lwt_GetFaceGeometry: lwt_be_getEdgeByFace returned 9295 edges
00.064573 psql:run.sql:13: NOTICE:  Calling GEOSBuildArea
04.274190 psql:run.sql:13: NOTICE:  GEOSBuildArea returned
04.288743 psql:run.sql:13: DEBUG:  [../../liblwgeom/lwgeom_topo.c:lwt_ChangeEdgeGeom:3499] lwt_ChangeEdgeGeom: lwt_GetFaceGeometry returned a polygon with 359909 vertices

[strk]

GEOS-3.9 seems to be faster than 3.8!

00.032633 psql:run.sql:13: DEBUG:  [../../liblwgeom/lwgeom_topo.c:lwt_GetFaceGeometry:2834] lwt_GetFaceGeometry: lwt_be_getEdgeByFace returned 9295 edges
00.037702 psql:run.sql:13: NOTICE:  Calling GEOSBuildArea
00.868618 psql:run.sql:13: NOTICE:  GEOSBuildArea returned
00.874062 psql:run.sql:13: DEBUG:  [../../liblwgeom/lwgeom_topo.c:lwt_ChangeEdgeGeom:3499] lwt_ChangeEdgeGeom: lwt_GetFaceGeometry returned a polygon with 359909 vertices

[strk]

The slowdown affects PostGIS Topology operation as reported here:
https://trac.osgeo.org/postgis/ticket/5111

[strk]

GEOS-3.10 is also slow as GEOS-main so the regression is between 3.9 and 3.10

00.097480 psql:run.sql:13: DEBUG:  [../../liblwgeom/lwgeom_topo.c:lwt_GetFaceGeometry:2834] lwt_GetFaceGeometry: lwt_be_getEdgeByFace returned 9295 edges
00.113386 psql:run.sql:13: NOTICE:  Calling GEOSBuildArea
04.544339 psql:run.sql:13: NOTICE:  GEOSBuildArea returned
04.555499 psql:run.sql:13: DEBUG:  [../../liblwgeom/lwgeom_topo.c:lwt_ChangeEdgeGeom:3499] lwt_ChangeEdgeGeom: lwt_GetFaceGeometry returned a polygon with 359909 vertices

[strk]

From PostGIS I can already spot the difference using ST_Polygonize, which according to git repository didn't get many changes between 3.9 and 3.10 so now I'm wondering if the CMake based build (enforced in 3.10) dropped the default compiler optimization.

Time passes: YES, while automake had -O2 by default, the cmake build does not pass any -O switch to the compiler. Is this a known issue ?

[pramsey]

cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo ../geos-dir

[strk]

Setting CXXFLAGS environment does not hav any effect ?

[pramsey]

None that I can see.

[dbaston]

CMake defaults to a Release build type, which uses -O3 for me but may depend on the platform.

[strk]

Confirmed, it was lack of optimization flags. I'll change the configure script handling of --enable-debug to use RelWithDebInfo