Opened 7 years ago

Closed 7 years ago

#5665 closed enhancement (worksforme)

Huge performance loss with latest trunk

Reported by: vindoctor Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: svn-trunk
Severity: normal Keywords:
Cc:

Description

I've attached my callstack below. I use to have acceptable multithreaded performance with gdal version 1.x. However, with 2.0(trunk) it seems a mutex is stopping all my threads. The virtual dataset sits on top of the tiff driver. What is pasted below is the location where all the threads are hung on a mutex, except the thread that got in(obviously ). I've pasted the callstack of the thread that gets into the tiff driver below as well. This is critical to us as what use to take seconds(sometimes milliseconds) now takes minutes. If this is not a bug(which I hope we find it is and is its a simple fix I can add today), can this get quickly designed out? I would hate to back out to version 1.x just because of this issue, as already have so much time invested into this version 2.

Thanks, V

gdal200.dll!_CPLAcquireMutex() + 0x6f bytes C++

gdal200.dll!_CPLCreateOrAcquireMutex() + 0xc0 bytes C++ gdal200.dll!CPLMutexHolder::CPLMutexHolder() + 0x26 bytes C++ gdal200.dll!GDALRasterBlock::SafeLockBlock?() + 0x47 bytes C++ gdal200.dll!GDALRasterBand::TryGetLockedBlockRef?() + 0x54 bytes C++ gdal200.dll!GDALRasterBand::GetLockedBlockRef?() + 0x37 bytes C++ gdal200.dll!VRTWarpedDataset::ProcessBlock?() + 0x33b bytes C++ gdal200.dll!VRTWarpedRasterBand::IReadBlock() + 0x31 bytes C++ gdal200.dll!GDALRasterBand::GetLockedBlockRef?() + 0xeb bytes C++ gdal200.dll!GDALRasterBand::IRasterIO() + 0x46c bytes C++ gdal200.dll!GDALRasterBand::RasterIO() + 0x1ab bytes C++ gdal200.dll!VRTSimpleSource::RasterIO() + 0xaa bytes C++ gdal200.dll!VRTSourcedRasterBand::IRasterIO() + 0x212 bytes C++ gdal200.dll!GDALRasterBand::RasterIO() + 0x1ab bytes C++

/the one that got in:

msvcr80.dll!malloc(unsigned int size=128843776) Line 163 + 0x63 bytes C

msvcr80.dll!malloc(unsigned int size=32768) Line 163 + 0x63 bytes C gdal200.dll!VSICachedFile::LoadBlocks?() + 0x247 bytes C++ gdal200.dll!VSICachedFile::Read() + 0x178 bytes C++ gdal200.dll!_VSIFSeekL() + 0x19 bytes C++ gdal200.dll!TerragenDataset::`vector deleting destructor'() + 0x36 bytes C++ gdal200.dll__TIFFprintAsciiTag() + 0xe5 bytes C gdal200.dll!_TIFFFillStrip() + 0x242 bytes C gdal200.dll!_TIFFReadEncodedStrip() + 0xd0 bytes C gdal200.dll!GTiffRasterBand::IReadBlock() + 0x472 bytes C++ gdal200.dll!GDALRasterBand::GetLockedBlockRef?() + 0xeb bytes C++ gdal200.dll!GDALRasterBand::IRasterIO() + 0x160 bytes C++ gdal200.dll!GTiffRasterBand::IRasterIO() + 0x1e4 bytes C++ gdal200.dll!GDALDataset::IRasterIO() + 0x11e bytes C++ gdal200.dll!GTiffDataset::IRasterIO() + 0x170 bytes C++ gdal200.dll!GDALDataset::ValidateRasterIOOrAdviseReadParameters() + 0x12a bytes C++ gdal200.dll!_GDALDatasetRasterIO@60() + 0x76 bytes C++ gdal200.dll!GDALWarpOperation::WarpRegionToBuffer?() + 0x308 bytes C++ gdal200.dll!VRTWarpedDataset::ProcessBlock?() + 0x2e3 bytes C++ gdal200.dll!VRTWarpedRasterBand::IReadBlock() + 0x31 bytes C++ gdal200.dll!GDALRasterBand::GetLockedBlockRef?() + 0xeb bytes C++ gdal200.dll!GDALRasterBand::IRasterIO() + 0x46c bytes C++ gdal200.dll!GDALRasterBand::RasterIO() + 0x1ab bytes C++ gdal200.dll!VRTSimpleSource::RasterIO() + 0xaa bytes C++ gdal200.dll!VRTSourcedRasterBand::IRasterIO() + 0x212 bytes C++ gdal200.dll!GDALRasterBand::RasterIO() + 0x1ab bytes C++

Change History (3)

comment:1 Changed 7 years ago by vindoctor

Priority: highnormal
Severity: blockernormal
Type: defectenhancement

Changed back to normal and make enhancment. I found that this got turned on. When I turned it off, our threads are not all stuck on the mutex and we are in parallel again.

CPLSetConfigOption("VSI_CACHE", "TRUE" );

comment:2 Changed 7 years ago by Even Rouault

How did you get VSI_CACHE set to TRUE ? This isn't automatically set by GDAL. I know QGIS does set it however.

It might be possible that VSI caching has negative performance effects with some read patterns where small amount of data must be fetched.

The other point is that the global cache mutex hits in that use case. There's an RFC ( http://trac.osgeo.org/gdal/wiki/rfc47_dataset_caching ) in development related to that

comment:3 Changed 7 years ago by Even Rouault

Resolution: worksforme
Status: newclosed

Closing due to lack of reporter feedback

Note: See TracTickets for help on using tickets.