mmap

This weekend I substantially re-wrote the DPX support with the hope of 
significant performance improvements, but the end result was a 
noticeable, but relatively small gain.  Reading files is over 2X (or 
3X) faster than writing files.  Since the algorithms for reading and 
writing are remarkably similar, I can only imagine that the difference 
comes from using memory mapping to access input files, but using 
stdio's fwrite() to access output files.  DPX does file access based 
on a 32-bit word level.

The Blob I/O interface is quite simplistic.  For memory-mapped input 
files this is ok, but when writing 32-bit words, there is a call to 
fwrite() for every word, with no buffering other than that offered by 
stdio.  I could add extra intermediate buffering in the coder, but 
that seems like the wrong approach since it does not address the root 
problem.

It is quite possible to use mmap() to write to output files.  In order 
for this to work, the file must be extended beyond the current write 
point using an API like ftruncate().  This is very similar to how 
it is common to allocate spare data when using realloc().  When all of 
the output has been writen, the file would be truncated down to the 
final size (once again using ftruncate()).  This could be done when 
the blob is closed.

Although it seems reasonable to assume that the I/O approach is the 
reason for the performance difference, I have not yet done a profiled 
build, or done a detailed investigation, in order to see for sure.

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