A sick idea - mmapped file output

[Michael Meissner]

On Thu, Nov 02, 2000 at 09:40:53PM -0800, Zack Weinberg wrote:
> The standalone preprocessor has a performance problem on its output
> end.  We do lots and lots of short fputs calls, and this can take up
> to 50% of total CPU time.  The sensible thing to do is to bypass
> stdio; we already do that on the input end, so there are no additional
> portability concerns.

Just as a data point -- I have used systems in the past where writes via mmap
did not always get read properly via read, due to mmap not updating the buffer
cache.  Now, this particular system (OSF/1 as delivered by OSF) is long since
dead, and this case of writing the entire file and closing it before the read
is likely to work, but I thought I would mention it.  Also whether you get
different semantics if $TMPDIR points to a NFS file system.

Another thought is that it may be the implementation of fputs that is slow
(maybe it is done in terms of calls to fputc?), and maybe a special purpose
implementation would work better.  Have you tried increasing the size of the
stdio buffer?

Finally, writev may win providing the OS implements writev in a smart fashion
(rather than having libc iterate with multiple writes, which some system have
used in the past).

> We get some nice performance wins by loading large headers with mmap
> instead of read, because the kernel can then read ahead while we
> process the file, instead of having to get everything into memory
> before read(2) returns.  So I was trying to think of a way to do the
> equivalent on the write end.  The basic problem with mmap for output
> is we don't know how much space we need ahead of time, and mmap won't
> extend the file for you.  Even if you request a mapping bigger than
> the file, you get lethal signals if you try to write past the end.
> 
> However, you can anticipate running off the end and extend the file
> with ftruncate.  POSIX and SUS don't guarantee that this works, but
> assuming it does, this is indeed faster than write(2) - until you run
> out of mapping, at which point you have a problem.  Or, even cleverer,
> you can catch the signal and extend it then, but this doesn't seem to
> be any faster than anticipating the end (not surprising; signals ain't
> cheap).  

I have used systems in the past where userlevel signals weren't able to handle
this.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482