LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
November 2008
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
2008.11.17 22:22 "Re: Memory leak (TIFFOpen, TIFFReadTile)?", by Bob Friesenhahn
On Mon, 17 Nov 2008, jcupitt@gmail.com wrote: > To summarise, I'm a bit surprised as I thought that mmap did have some > performance advantages. It certainly did 15 years ago, or whenever it > was that we were all so excited about it. I guess read() has become a > lot better. But I'm not sure that mmap() has any real disadvantages > either, at least in this case (local disc). I didn't try a networked > device. Note that mmap() still does a "read()" but it does so by trapping to the kernel if there is a MMU hard page fault. The trap will update at least one page, but if the OS is smart enough to detect sequential access, then it is likely to speculatively read multiple pages so they are already in memory when needed. Typically a kernel thread does the read on behalf of the application. With a well written program, the result is less CPU time consumed by the application. With today's fast CPUs that CPU time is a lot less prohibitive than it used to be. Regardless, if the system has enough RAM and address space to buffer the entire file, a second read should be faster. I find that libtiff's file access is quite efficient and believe that we should observe the rule "If it ain't broke, don't fix it". If someone wants to make libtiff faster, then it would be useful to tune up the file decompressors/compressors and perhaps augment them with OpenMP so that they can go a lot faster on multi-core systems without much work. Bob ====================================== Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/