<html><head><style type="text/css">.style1 {font-family: "Times New Roman";}</style></head><body><div dir="ltr"><div id="gmail-:2o4" class="gmail-Am gmail-aiL gmail-aO9 gmail-Al editable gmail-LW-avf gmail-tS-tW gmail-tS-tY" aria-label="Message Body" role="textbox" aria-multiline="true" tabindex="1" style="direction:ltr;min-height:85px" aria-controls=":2r1" aria-expanded="false">All,<div><br></div><div>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:</div><div><br></div><div>proj_trans_generic(): 0.211000 seconds <br>OGRCoordinateTransformation::Transform(): 0.212000 seconds</div><div><br></div><div>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,</div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Mar 6, 2026 at 2:11 PM David Klaus <<a href="mailto:dklaus@carlsonsw.com">dklaus@carlsonsw.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Even,<div><br></div><div>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,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 6, 2026 at 1:00 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>Hi,</p>
<p>It would be interesting if you could bench using proj_trans() or
proj_trans_array() vs <a>OGRCoordinateTransformation::Transform()</a>. My
gut feeling would be that the CPU cost of most coordinate
transformations would be the dominant part, but I might be wrong.</p>
<p>Even</p>
<div>Le 06/03/2026 à 18:40, David Klaus via
gdal-dev a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hello GDAL Community,<br>
<br>
I am currently optimizing a routine that transforms a large
number of points using <a>OGRCoordinateTransformation::Transform()</a>.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Alternatively is this separation intentional, making my cache
concerns less of an issue in practice?<br>
<br>
Thank you for your time and any insights you can provide,
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">David Klaus
<div>Carlson Software</div>
</div>
</div>
</div>
<br>
<br>
<p style="font-family:Verdana;font-size:10pt;color:rgb(119,119,119)"><b>Disclaimer</b></p>
<p style="font-family:Verdana;font-size:8pt;color:rgb(119,119,119)">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.</p>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
gdal-dev mailing list
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">David Klaus<div>Carlson Software</div></div></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">David Klaus<div>Carlson Software</div></div></div>
<br><br><p style="font-family: Verdana; font-size:10pt; color:#777777;"><b>Disclaimer</b></p><p style="font-family: Verdana; font-size:8pt; color:#777777;">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.</p></body></html>