Increate BUFSIZ to 8192

[imp]

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

[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).

[• ian]

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().

[peterj]

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.