On Fri, 28 Jul 2000, Paul J. Lucas wrote:
> On Fri, 28 Jul 2000, Kenneth Lee wrote:
>
> > it would be good for the user to choose between mmap or normal i/o at
> > compile time. i'll try HTML::Tree anyway in the meantime.
>
> It's not that simple. Using mmap(2) greatly affects how one
> writes code: it's not a drop-in replacement for standard I/O.
> An mmap'd file *becomes* memory in the time it takes the OS to
> handle a page-fault. You then further get speed by accessing
> the file *as* memory via ordinary pointers rather than function
> calls and I/O buffers. Inside the HTML Tree code is a generic
> C++ STL-style container class wrapped around mmap...quite nice
> if I do say so myself.
>
> By definition, file I/O off disk can't be faster than mmap(2).
This is the quote from "Philip and Alex..." that I was talking about
earlier. I don't know if its relevant or not:
>>
My favorite AOLserver story starts in the seventh-floor lounge of the MIT
Artificial Intelligence Laboratory. I was asking Robert Thau, primary
author of the Apache server program, why the Netscape 1.1 server was so
slow. He said "Oh that's because those guys don't understand Unix.
They're actually using the read system call to read files." Everyone in
the room laughed except me. What? What's wrong with that? I asked. He
replied, "Everyone knows you can't use read; you have to use memory-mapped
I/O."
I knew that the NaviSoft guys were about to release a new version so I
thought I'd give the naifs in Santa Barbara the benefit of some hard-core
MIT engineering knowledge. I told them the story and asked them what
NaviServer, as it was then called, did. They replied "NaviServer uses
memory-mapped file I/O on single-processor machines but automatically
configures itself to use operating system read on multi-CPU machines so
as to reduce shared memory contention."
<<
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
