Page MenuHomeFreeBSD

Increate BUFSIZ to 8192

Authored by bapt on May 11 2015, 10:50 PM.



Diff Detail

rS FreeBSD src repository - subversion
Lint OK
No Unit Test Coverage

Event Timeline

bapt retitled this revision from to Increate BUFSIZ to 8192.
bapt updated this object.
bapt edited the test plan for this revision. (Show Details)
imp added a reviewer: imp.

This is a world ending event.
But I have marshmallows, a stick and know where some graham crackers and chocolate are.

This revision is now accepted and ready to land.May 11 2015, 10:52 PM
delphij added a reviewer: delphij.
delphij added a subscriber: delphij.

I think this would be a good move.

(I assume that you have done a full ports/ build already? I don't expect problems as 8K is the glibc value of BUFSIZ but it's a good idea to exercise the bits more before we make a change as it seems to be slightly increasing stack usage for some callers).

There are 2125 occurrances of BUFSIZ in the base code (probably 95% of them inappropriately used to size a local temp buffer or string). You really want to perturb that much working tested software because it makes md5 faster? How many of those occurrances are stack-allocated variables and is it wise to allocate 8k buffers on the stack for all of them? How about existing programs (not necessarily in base) that open many streams concurrently... what will be the impact of a sudden 8x increase in memory usage for them?

It seems to me that if libmd needs bigger buffers to perform well, it should use setvbuf().

I've been bitten in the past by a buffer size change causing unexpected breakage (bin/144446) and would be wary of making this change without extensive testing. The claimed benefit is improved performance - in which case, I'd expect more justification than a single md5 and sha256 test. What does ministat(1) report on 3-5 runs?

For a slightly more useful test, what impact does this have on (eg) buildworld speed and size?

All the above said, I think it's a reasonably good idea for BUFSIZ to be larger.