> Neeraj Singh <nksingh85@xxxxxxxxx> writes: > > I collected data from an experiment with different buffer sizes on Windows on my > > 3.6Ghz Xeon W-2133 machine: > > https://docs.google.com/spreadsheets/d/1Bu6pjp53NPDK6AKQI_cry-hgxEqlicv27dptoXZYnwc/edit?usp=sharing > > > > The timing is pretty much in the noise after we pass 32K. So I think > > 8K is too small, but > > given the flatness of the curve we can feel good about any value above > > 32K from a performance > > perspective. I still think 128K is a decent number that won't likely > > need to be changed for > > some time. Linux/BSD/etc `stat` system calls report st_blksize values to tell user code the optimal size for read and write calls. Does Windows have one? (It's not POSIX but is XSI.) (How *well* the OS reports `st_blksize` is another question entirely, but at least if the report says, say, 128k, and that's wrong, that's no longer Git's fault. :-) ) On Wed, Feb 24, 2021 at 10:46 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > Thanks for a supporting graph. > > I can very well imagine that it would have been tempting to instead > say "after we pass 128k" while explaining exactly the same graph, > and doing so would have given a more coherent argument to support > the choice of 128k the patch made. You knew that a "then perhaps we > can reclaim 96k by sizing the buffer down a bit?" would become a > reasonable response, but you still chose to be honest, which I kinda > like ;-) 128K is correct for ZFS; 64K is typically correct for UFS2; 8K is the old UFS1 size. Anything under that has been too small for a long time. :-) Chris
