Jan,
What are those 3.03 and 3.53 versions ? They don't match GDAL official
version numbers. I thought you meant 3.0.3 and 3.5.3, but the LVBAG
driver is new to 3.2.0, so that can't be it. Xerces is *not* a required
DLL for that driver. It uses Expat. Do you use the
AUTOCORRECT_INVALID_DATA=YES open option? If so, the difference could
come from the GEOS version
Even
Le 10/11/2024 à 09:58, Jan Heckman via gdal-dev a écrit :
My c++ utility-app collects Kadaster BAG data in postgresql tables for
use in "populatie service".
It has functioned for several years, with a typical runtime of 40 minutes.
In the process of rounding this off, I updated the gdal binaries from
3.03 to 3.53, as well as added some threaded workloads for analyzing
the tables.
Confusingly, the runtime went up to 4 hours and more. This is after
the download, so internet speed has no role here. It's all local, no
network and my PC has not degraded. I have tried to reconstruct an
older setup, but failed to get it back up to speed.
Profiling and random breaks during waiting point conclusively to the
function getting features from a layer.
LVBAG processes lots of xml of a specific (but not highly particular)
structure.
My app is compiled, if so indicated, against expat. Xerces is also a
required dll.
So my first idea was that there might be a serious performance
difference between xml libs, but without direct evidence.
I am using gdal windows binaries from Gisinternals.
All suggestions are welcome!
Thanks in advance,
Jan
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is
just about bytes.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
