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. Thanks! -NGie
signature.asc
Description: Message signed with OpenPGP using GPGMail
