From: | ncm(at)zembu(dot)com (Nathan Myers) |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: BSD gettext |
Date: | 2001-05-24 21:10:34 |
Message-ID: | 20010524141034.Q18121@store.zembu.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 24, 2001 at 10:30:01AM -0400, Bruce Momjian wrote:
> > The HPUX man page for mmap documents its failure return value as "-1",
> > so I hacked around this with
> >
> > #ifndef MAP_FAILED
> > #define MAP_FAILED ((void *) (-1))
> > #endif
> >
> > whereupon it built and passed the simple self-test you suggested.
> > However, I think it's pretty foolish to depend on mmap for such
> > little reason as this code does. I suggest ripping out the mmap
> > usage and just reading the file with good old read(2).
>
> Agreed. Let read() use mmap() internally if it wants to.
The reason mmap() is faster than read() is that it can avoid copying
data to the place you specify. read() can "use mmap() internally" only
in cases rare enough to hardly be worth checking for.
Stdio is often able to use mmap() internally for parsing, and in
glibc-2.x (and, I think, on recent Solarix and BSDs) it does. Usually,
therefore, it would be better to use stdio functions (except fread()!)
in place of read(), where possible, to allow this optimization.
Using mmap() in place of disk read() almost always results in enough
performance improvement to make doing so worth a lot of disruption.
Today mmap() is used heavily enough, in important programs, that
worries about unreliability are no better founded than worries about
read().
Nathan Myers
ncm(at)zembu(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-05-24 21:11:09 | Re: BSD gettext |
Previous Message | Hannu Krosing | 2001-05-24 21:05:19 | Re: Plans for solving the VACUUM problem |