Not sure I understand the disagreement. "the correct buffer size is often per file, not per program/invocation, so a one-size-fits-all envar is the wrong approach"- if you're saying "it would be great to have the buffer size be an option to 'open'," then I agree. It would be nice to have that settable as a parameter. At the moment, you can set it by file by changing $*DEFAULT-READ-ELEMS then creating the filehandle- I read the source, and the handle saves the value it was given. If you change the variable later and open a new handle, the new handle gets the new value while the old keeps its old value. While being able to explicitly set it per handle would be good, the implementation of this dynamic variable is a workable first step.
" it is rare for the buffer size to be different based on the system except on systems so small that rakudo isn't going to work on them anyway (e.g. embedded systems)." That doesn't make sense to me, before Elizabeth's patch the buffer was never different on any system, it was always 64K. (And I thought I saw Rakudo on Raspberry Pi in 2014 or '15 but not sure...) 'I can't see this impacting much in the common case" right this isn't addressing common cases. it's an "infrequently asked question." I wasn't even thinking of small systems, but large ones with SAN networks using clever caching over not-quite-properly configured VLANs- like what I use at work. Some of our servers use the SAN through a different VLAN. I don't expect a programmer to fine-tune file-processing code for my situation (unless they want to on-the-fly find the best buffer size each run!), I do appreciate being able to set the buffer in the environment per-system, and I was the original person asking to be able to set the buffer and I have seen it make a difference in this use case. "In the specific case that prompted this thread, it is the programmer that wants to specify a very large buffer." In my case, I was comparing perl5 with C#, and I found that for that particular system, code, and file, a buffer size of 128k was the sweet spot. "is a small system even going to be able to handle that much data to begin with?" Not sure how the existence of small systems eliminates the usefulness of twiddling buffer sizes. -y
