LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
March 2005
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2005.03.30 15:17 "Re: RFC: fast 'copy free' tiff decoding", by Bob Friesenhahn
On Wed, 30 Mar 2005, Joris wrote: > > If I'm interpreting your goals correctly, I'm afraid you might be confusing the > issue with all this talk about memory maps and other implementation issues. I've > personally always considered memory mapping TIFFs a bad idea. There's no telling > what size files you might need to handle, especially with the new BigTIFF > format. You could need to eat 8 gig of address space on a machine that is > theoretically limited to 2 gig for memory maps, and shares this 2 gig with other > applications, like I think is the case on common windows systems. Moreover, > there seems very little benefit to abusing address space like this, as opposed > to good ol' plain file IO, especially given the fact that you'll need to aling > and byteswap in seperately allocated memory blocks anyhow. It is not necessary to map the entire file at once. A relatively small "peephole" of memory mapping (e.g. 256K) may be used to access large files. There is not much overhead associated with the map/unmap process. The key thing is if the memory mapping API is able to support large files. For POSIX mmap(), this is determined by the size of the off_t type. For Large File System (LFS) builds, or POSIX operating systems which support large files by default, off_t has at least 63 usable bits. Bob ====================================== Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/