2019.10.02 13:29 "Re: [Tiff] TIFF_IO_MAX too large for Windows XP", by Bob Friesenhahn
And by the way - the performance hit of using smaller buffers is barely noticeable - at least not with TIF files of a couple of hundred MB
Note that TIFF_IO_MAX seems to be an absolute limit. This value should only be used if an exceptionally large read/write size (larger than that value) was requested. Before one can do an I/O with a size of TIFF_IO_MAX, it is necessary to have allocated at least this much memory in a single allocation since the data needs somewhere to go. To me it raises a red flag if TIFF_IO_MAX is being hit in the first place. It is unlikely that such a high limit is hit unless using BigTIFF on an extremely large file or the input file is corrupt. Windows 32-bit apps can not normally access more than 2GB of memory in the first place due to address space limitations, and often the memory allocator will not agree to allocate anything close to that much.
I agree that file I/O in smaller chunks is rarely harmful and in fact some operating systems will behave better when using smaller chunks if the chunks perfectly match the filesystem block size, or the additional I/O requests wake up sequential I/O optimizations in the kernel, or the kernel implementation has buffering issues.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt