After further investigation I found that the order in which the CMyClass
instances are destroyed matter. delete[] destroys them in reverse order while
the vector destroys them in a forward order.
I could emulate both ways by using placement new:
#include
#include
int SINGLE_ALLOC_SIZE =
I was curious and gave it a try. I also saw the bad performance on
deallocations, but surprisingly the usage of a std::vector in the outer loop
speeds things up considerably.
I could still see a peak memory usage of 1.8GiB, so it does not seem as if the
compiler did optimize something out.
Hi Even,
you’re right. We also know that. When programming the driver I took it in
consideration. Our solution is not rely on windows to make a good job with
memory and we try to reuse as memory as possible instead of use calloc/free
freely.
For instance, in the driver, for each feature I
In my company we confirmed that "Windows heap allocation mechanism sucks."
Closing the application after using gtiff driver can take many seconds due
to memory deallocations.
One workaround was to use tcmalloc. I will ask my colleagues more details
next week.
On Thu, 21 Mar 2024, 01:55 Even
Hi,
while investigating
https://github.com/OSGeo/gdal/issues/9510#issuecomment-2010950408, I've
come to the conclusion that the Windows heap allocation mechanism sucks.
Basically if you allocate a lot of heap regions of modest size with
malloc()/new[], the time spent when freeing them all
