Hi,
It would be interesting if you could bench using proj_trans() or
proj_trans_array() vs OGRCoordinateTransformation::Transform(). My gut
feeling would be that the CPU cost of most coordinate transformations
would be the dominant part, but I might be wrong.
Even
Le 06/03/2026 à 18:40, David Klaus via gdal-dev a écrit :
Hello GDAL Community,
I am currently optimizing a routine that transforms a large number of
points using OGRCoordinateTransformation::Transform().
As it stands, this function requires separate arrays for the x, y, z
(optional), and t (optional) data. From a memory perspective, it seems
that this approach requires the CPU to fetch cache lines from multiple
different memory pools to process a single coordinate tuple. I am
concerned this might lead to cache thrashing and degraded performance
for massive arrays.
Is there an existing method or best practice to provide point data to
GDAL in an interleaved, cache-friendly manner? I believe that this can
be done using proj directly, but I don't see a solution with GDAL.
Alternatively is this separation intentional, making my cache concerns
less of an issue in practice?
Thank you for your time and any insights you can provide,
--
David Klaus
Carlson Software
*Disclaimer*
The information contained in this communication from the sender is
confidential. It is intended solely for use by the recipient and
others authorized to receive it. If you are not the recipient, you are
hereby notified that any disclosure, copying, distribution or taking
action in relation of the contents of this information is strictly
prohibited and may be unlawful.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
