<div dir="auto">In my company we confirmed that "Windows heap allocation mechanism sucks."<div dir="auto">Closing the application after using gtiff driver can take many seconds due to memory deallocations.</div><div dir="auto"><br></div><div dir="auto">One workaround was to use tcmalloc. I will ask my colleagues more details next week.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 21 Mar 2024, 01:55 Even Rouault via gdal-dev, <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
while investigating <br>
<a href="https://github.com/OSGeo/gdal/issues/9510#issuecomment-2010950408" rel="noreferrer noreferrer" target="_blank">https://github.com/OSGeo/gdal/issues/9510#issuecomment-2010950408</a>, I've <br>
come to the conclusion that the Windows heap allocation mechanism sucks. <br>
Basically if you allocate a lot of heap regions of modest size with <br>
malloc()/new[], the time spent when freeing them all with corresponding <br>
free()/delete[] is excruciatingly slow (like ~ 10 seconds for ~ 80,000 <br>
allocations). The slowness is clearly quadratic with the number of <br>
allocations. You only start noticing it with ~ 30,000 allocations. And <br>
interestingly, another condition for that slowness is that each <br>
individual allocation much be strictly greater than 4096 * 4 bytes. At <br>
exactly that value, perf is acceptable, but add one extra byte, and it <br>
suddenly drops. I suspect that there must be a threshold from which <br>
malloc() starts using VirtualAlloc() instead of the heap, which must <br>
involve slow system calls, instead of a user-land allocation mechanism.<br>
<br>
Anyone has already hit that and found solutions? The only potential idea <br>
I found until now would be to use a private heap with HeapCreate() with <br>
a fixed maximum size, which is a bit problematic to adopt by default, <br>
basically that would mean that the size of GDAL_CACHEMAX would be <br>
consumed as soon as one use the block cache.<br>
<br>
Even<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank" rel="noreferrer">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>