[gdal-dev] OGRCoordinateTransformation::Transform() memory usage clarification

[Even Rouault]

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
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260306/6d9ce6f1/attachment.htm>