Re: Writev system call
- From: Logan Shaw <lshaw-usenet@xxxxxxxxxxxxx>
- Date: Sun, 06 Jan 2008 05:20:30 -0600
chsalvia@xxxxxxxxx wrote:
Is there generally a performance advantage in using the writev/readv
system calls, rather than simply iterating through an array and
calling read/write individually?
I would imagine there would be an advantage, because there is only one
system call as opposed to multiple, but I wonder if writev/readv might
simply be implemented by making multiple system calls to write/read.
Consider what may happen to fulfill the I/O requests and whether it
helps the underlying code to know about everything (to know about all
the I/O requests) up front.
For example, if you are writing to a TCP stream, 5 writes of 100 bytes
each may (with a naive implementation) cause 5 packets to be sent out.
Since each packet has an TCP header, an IP header, and some other
overhead (like a MAC address with Ethernet), you are increasing your
overhead.
Or consider what may happen if you are writing to a pipe. Potentially,
as soon as you've written the first 100-byte chunk, you may have a
context switch and the pipe's reader could wake up and start processing
the data. Then the pipe's reader would block when it has used up all
its input, and the writer would be reawakened. In the worst case, there
might be two context switches for every call to write().
Or for yet another example, consider what happens if you are writing
to a terminal. Many terminals behave in such a way that if several
newlines come in a short period of time, they do a "fast scroll"
where they avoid copying everything on the screen up one line only
to move it up another line immediately afterwards and instead they
move it up two (or more) lines at once. If you break things up into
separate write()s, the terminal could have to do more copying of
stuff around on the screen and might scroll more slowly.
Basically, writev() allows you to share all of your knowledge with
the implementation (of the filesystem, the terminal, the network stack,
or whatever else is doing the file operations) immediately. With
multiple write() calls, the implementation doesn't know more data is
coming soon, so it can't do tricks that might speed things up in light
of that fact. The more you know in advance about what you're going
to be doing, the more opportunities you may have to optimize it.
Also, in a sense, this is just a special case of the adage that
"batch mode processing is always more efficient". writev() is
effectively letting you submit the I/O work in batches.
- Logan
.
- References:
- Writev system call
- From: chsalvia
- Writev system call
- Prev by Date: Re: Writev system call
- Next by Date: Re: Is there an ANSI C compatible kill()?
- Previous by thread: Re: Writev system call
- Next by thread: Re: Writev system call
- Index(es):
Relevant Pages
|
