On May 14, 2015, at 1:01, Poul-Henning Kamp <p...@phk.freebsd.dk> wrote:

> --------
> In message <1431542835.1221.30.ca...@freebsd.org>, Ian Lepore writes:
>> On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote:
>> As I've already pointed out, BUFSIZ appears in the
>> base code over 2000 times.  Where is the analysis of the impact an 8x
>> change is going to have on all those uses?
> Not to pick on Ian in particular, but I'm going to call bike-shed
> on this discussion now.
> Please just make it 4K on 32bit archs and 16K on 64 bit archs, and
> get on with your lives.
> If experience in -current (that's why developers run current, right ?!)
> documents that this was the wrong decision, we can revisit it.
> Until then:  Shut up and code.

Baptiste’s recommendation was related to md5 performance, so it might be that 
(as you pointed out with MDXFileChunk), things might be less performant in the 
application than they could be — but that’s an application bug (only helped by 
scaling issues with FreeBSD, potentially). Until performance has been 
characterized on 32-bit vs 64-bit architectures, blanket changing a value 
doesn’t make sense.

I think that changing buffers sized at BUFSIZ for md5/libmd5 probably makes a 
lot more sense as that change is isolated and the end result could be easily 
micro benchmarked. If/when we have an overall characterization we can look at 
increasing the value across the board.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to