Re: [gdal-dev] gdal-dev Digest, Vol 238, Issue 82

1x1251, 625x625, 312x312 ? Unit Type: US survey foot ? Metadata: ? ? STATISTICS_APPROXIMATE=YES ? ? STATISTICS_MAXIMUM=1604.9490966797 ? ? STATISTICS_MEAN=988.29463693706 ? ? STATISTICS_MINIMUM=669.50915527344 ? ? STATISTICS_STDDEV=159.80361228109 ? ? STATISTICS_VALID_PERCENT=100 -

Re: [gdal-dev] USGS 3DEP (3D Elevation Program) - feet should be metres, how can I fix this?

Le 21/03/2024 à 21:45, Conrad Bielski via gdal-dev a écrit : Hello GDALers, I have a question about reading USGS 3DEP (3D Elevation Program) data. Inside of this data, a GEOTIFF tag 42114 is provided which is causing problems with datum shifts. There's no such thing as a GEOTIFF tag 42114.

[gdal-dev] USGS 3DEP (3D Elevation Program) - feet should be metres, how can I fix this?

Hello GDALers, I have a question about reading USGS 3DEP (3D Elevation Program) data. Inside of this data, a GEOTIFF tag 42114 is provided which is causing problems with datum shifts. So when I use GDAL to compute the datum shifts, the tag is read and interprets that the DEM is showing

Re: [gdal-dev] Compiling Poppler plugin under Windows (missing dependencies with GisInterrnals)

Thanks Even. As far as Gisinternals is concerned, I think they are still using "nmake" to compile the PDF plugin (see makefile ). This may explain why they don't need the POPPLER_EXTRA_LIBRARIES parameter. Concerning the document, I

Re: [gdal-dev] [EXTERNAL] [BULK] Re: Experience with slowness of free() on Windows with lots of allocations?

I’ve used mimalloc successfully in the past, worth a look if a drop in replacement for new / delete / malloc / free is desirable. Do note that its performance is usually uniformly superior to glibc / msvc but there are unintuitive performance cliffs. Given the block nature of most gdal raster

Re: [gdal-dev] [EXTERNAL] [BULK] Re: Experience with slowness of free() on Windows with lots of allocations?

I've played with VirtualAlloc(NULL, SINGLE_ALLOC_SIZE, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE), and it does avoid the performance issue. However I see that VitualAlloc() allocates by chunks of 64 kB, so depending on the size of a block, it might cause significant waste of RAM, so that can't

Re: [gdal-dev] Experience with slowness of free() on Windows with lots of allocations?

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 =

Re: [gdal-dev] [EXTERNAL] [BULK] Re: Experience with slowness of free() on Windows with lots of allocations?

+1. We use a variety of hand-rolled VirtualAlloc based (for basic tasks, a simple pointer bump, and for more elaborate needs, a ‘buddy’) allocators, some of which try to be smart about memory usage via de-committing regions. In our work, we tend to disable the GDAL cache entirely and rely on

Re: [gdal-dev] Experience with slowness of free() on Windows with lots of allocations?

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.

Re: [gdal-dev] Compiling Poppler plugin under Windows (missing dependencies with GisInterrnals)

Philippe, I guess, I did not initialize POPPLER_EXTRA_LIBRARIES: * is its type STRING ? Yes * what separator should I use between library name ? Semicolon ';' I see this was added per https://github.com/OSGeo/gdal/commit/95ee1f855cd and

[gdal-dev] Compiling Poppler plugin under Windows (missing dependencies with GisInterrnals)

Hi, While compiling GDAL V3.8.4 under Windows (Visual Studio 17 2022), I would like to add the PDF plugin. I downloaded all dependencies from GisInternals . The PDF plugin compilation, based on Poppler, fails due to missing dependencies for poppler.lib. I found a

Re: [gdal-dev] Experience with slowness of free() on Windows with lots of allocations?

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

Re: [gdal-dev] Experience with slowness of free() on Windows with lots of allocations?

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