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

[David Klaus]

All,

I had a chance to write up and time a comparison. It looks like Even's
guess was correct. I compared the runtime of proj_trans_generic() vs.
OGRCoordinateTransformation::Transform() when transforming 1 million
points. Here are the results:

proj_trans_generic(): 0.211000 seconds
OGRCoordinateTransformation::Transform(): 0.212000 seconds

So it looks like the two approaches are very comparable, at least on my
machine. For larger arrays, memory thrashing might become more noticeable.
But, I don't have a dataset to test that on,

On Fri, Mar 6, 2026 at 2:11 PM David Klaus <dklaus at carlsonsw.com> wrote:

> Even,
>
> I could give this a try. I will add it as a subtask to my current case. I
> will update once I have more information -- hopefully sometime next week,
>
> On Fri, Mar 6, 2026 at 1:00 PM Even Rouault <even.rouault at spatialys.com>
> wrote:
>
>> 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 listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev <https://lists.osgeo.org/mailman/listinfo/gdal-dev>
>>
>> -- http://www.spatialys.com <http://www.spatialys.com>
>> My software is free, but my time generally not.
>>
>>
>
> --
> David Klaus
> Carlson Software
>


-- 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260310/7675202e/attachment-0001.htm>