Re: mmap

On Wed, 20 Apr 2005, Patrick Welche wrote:

> There couldn't be some affect like read-ahead when reading the disk at
> work? 2x seems a bit much to explain though..

Access to a memory-mapped file looks like a simple memory access to 
the code.  This is how files are read.  However, data is written using 
stdio and in the case of DPX is being written only four bytes at a 
time using fwrite().  Even though fwrite() benefits from stdio's 
internal buffering, there is much more function call overhead 
associated with using it.  The system is doing additional locking to 
make access thread safe even though we don't need that.

The main issue with using mmap() for writing files is that mmap() 
can't be used to extend the file.  A different API is used to extend 
the file before data is written.  Unix (and likely Windows NTFS) 
benefits from supporting "holes" in files so that if no data is 
written, space is not consumed and little time is expended.  It may be 
that filesystems (e.g. FAT) which do not support holes in files may 
extend files more slowly.  Then again, we are already using this for 
GraphicsMagick's temporary "cache" files.

Bob
======================================
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728