Date: Sat, 16 Feb 2013 14:26:23 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r246824 - head/lib/libc/stdio Message-ID: <20130216132623.GA25333@stack.nl> In-Reply-To: <20130216024443.N1029@besplex.bde.org> References: <201302151044.r1FAi8rs010160@svn.freebsd.org> <20130216024443.N1029@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 16, 2013 at 04:08:06AM +1100, Bruce Evans wrote: > On Fri, 15 Feb 2013, Jilles Tjoelker wrote: > > Log: > > setbuf(3): Remove bugs section about ancient versions of BSD. > > Modified: > > head/lib/libc/stdio/setbuf.3 > > Modified: head/lib/libc/stdio/setbuf.3 > > ============================================================================== > > --- head/lib/libc/stdio/setbuf.3 Fri Feb 15 09:10:01 2013 (r246823) > > +++ head/lib/libc/stdio/setbuf.3 Fri Feb 15 10:44:07 2013 (r246824) > > ... > > @@ -195,19 +195,3 @@ and > > functions > > conform to > > .St -isoC . > > -.Sh BUGS > > -The > > -.Fn setbuffer > > -and > > -.Fn setlinebuf > > -functions are not portable to versions of > > -.Bx > > -before > > -.Bx 4.2 . > > -On > > -.Bx 4.2 > > -and > > -.Bx 4.3 > > -systems, > > -.Fn setbuf > > -always uses a suboptimal buffer size and should be avoided. > This also removes the bugs section about setbuf() being unusable. It > uses a buffer of size BUFSIZ, but that is unusably small. This bug > is older than the old versions of BSD (setbuf() was broken as designed) > but still applies. So I should put back a BUGS section with the below? ] .Fn setbuf ] always uses a suboptimal buffer size and should be avoided. The risk is not very high because the lazy thing to do (not calling setbuf() at all) gives better results than calling setbuf(). > BTW, I recently noticed many utilities using too-small stdio buffers: > - md5(1) and libmd use raw BUFSIZ to get the same slowness as setbuf(). > They even try to get misaligned buffers by allocating them as char > arrays on they stack. md5(1) calls fread() for BUFSIZ bytes at a time. This causes more memory copies than necessary but does not affect the stdio buffer size passed to read(2). > - cmp(1) in the non-regular file case naively believe that stdio chooses > a good buffer size, and stdio naively believes that stat()'s > st_blksize is a good buffer size. The latter is still broken in the > kernel (it was unbroken a couple of years ago for regular files). Any way to fix stdio? > So cmp [-lx] on disks runs very slowly. cmp's internal algorithms > are also very slow (starting with using stdio at all), but can keep > up with disks provided the disks are slowed down like this. The > non-regular file case is little better. It uses mmap() and a > different slow internal algorithm (not quite as slow since it doesn't > use stdio). mmap() is especially suitable for disk files, but cmp > "knows" that it only works on regular files. cp(1) and install(1) use > mmap() more reasonably. mmap() is generally worse than read()/write() if you only access the data once. VM manipulations are not free. In the interest of simplicity it may be good to remove the extra code and only use read()/write(). -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130216132623.GA25333>