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.


Reply via email to