Path: utzoo!attcan!uunet!lll-winken!lll-tis!mordor!joyce!sri-unix!quintus!ok
From: ok@quintus
Newsgroups: comp.unix.questions
Subject: A warning about read(2)/write(2)
Message-ID: <122@quintus.UUCP>
Date: 16 Jun 88 02:18:31 GMT
Sender: news@quintus.UUCP
Reply-To: ok@quintus ()
Distribution: na
Organization: Quintus Computer Systems, Inc.
Lines: 25

Amongst the goodies recently posted to comp.sources.unix was one whose
README file said that it was a rewrite of a public domain version, and
that one of the changes that had been made was to use read(2)/write(2)/
lseek(2)/open(2)/close(2) for I/O instead of using stdio.

THAT WAS A BAD IDEA.

If you want to make your program's I/O more efficient, simply replacing
stdio calls by low-level UNIX calls is not a good idea.  If you use
stdio, that package will do I/O a buffer at a time, so you only get a
system call (and a disc access) when a buffer is filled or emptied.

The package I am talking about was reading and writing 56 byte chunks,
so it was doing a system call and a disc access for every 56 bytes.
(And since 56 does not divide 8192 evenly, some of these transfers
could cost two disc accesses.)

To make your disc I/O more efficient, do as few transfers as possible,
and do as much useful work as you can in each transfer.  For example,
in this balanced tree package, it would have been a good idea to keep
the tree as a tree of 8k "pages", each page containing a set of keys
(128 64-byte nodes would fit into a page, reducing the number of
disc accesses required by a factor of 7).

[This isn't a question, but it is the answer to a question that _should_
 have been asked before the package was written.]