Date: Mon, 19 Jan 2004 13:11:34 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: current@freebsd.org Subject: Re: Is BUFSIZ too small ? Message-ID: <200401192111.i0JLBYVk004060@apollo.backplane.com> References: <98336.1074543216@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
:I noticed that we still have BUFSIZ in stdio.h defined to only 1024,
:and wonder if that should be increased these days.
:
:Is there anybody who could devise and run some benchmarks to find
:out what effect it would have to increase it to for instance 4096 ?
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:phk@FreeBSD.ORG | TCP/IP since RFC 956
STDIO uses st.st_blksize sized I/O buffers by default, which will be
either 8K or 16K on most machines.
Very few programs use BUFSIZ for the actual I/O ops but libc seems
to use it for stack-declared buffers (e.g. like in
/usr/src/lib/libc/net/getservent.c, net/name6.c, net/gethostnamadr.c,
etc). vprintf uses it but I doubt that would impact performance.l
Unbuffered FILE I/O (setvbuf SNBF) will cause writes to be broken
down into BUFSIZ chunks... but who uses unbuffered I/O in that manner?
Not very many programs I would wager.
So, just at a guess, raising BUFSIZ could lead to unnecessary dirty
page bloat in most programs and would otherwise not improve performance.
It might be worth seeing what stdout's behavior is when the program
output runs through a pipe. If it is dropping down to BUFSIZ for pipes
it might be worth fixing __swhatbuf() in stdio/makebuf.c, but I still
wouldn't bother with BUFSIZ.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401192111.i0JLBYVk004060>