Skip site navigation (1)Skip section navigation (2)
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>