El 18/02/2010, a las 06:36, Junio C Hamano escribió: > Nicolas Pitre <nico@xxxxxxxxxxx> writes: > >> It is likely to have better performance if the buffer is small enough to >> fit in the CPU L1 cache. There are two sequencial passes over the >> buffer: one for the SHA1 computation, and another for the compression, >> and currently they're sure to trash the L1 cache on each pass. > > I did a very unscientific test to hash about 14k paths (arch/ and fs/ from > the kernel source) using "git-hash-object -w --stdin-paths" into an empty > repository with varying sizes of paranoia buffer (quarter, 1, 4, 8 and > 256kB) and saw 8-30% overhead. 256kB did hurt and around 4kB seemed to be > optimal for my this small sample load. > > In any case, with any size of paranoia, this hurts the sane use case, so > I'd introduce an expert switch to disable it, like this. Shouldn't a switch that hurts performance and is only needed for insane use cases default to off rather than on? Cheers, Wincent -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html