Perhaps the entity in the best position to figure out the optimum buffer size is the program itself.
The information on file size, available memory, &c is there, so a calculation when the file is opened ought to yield the answer for best performance. On 4/2/16, yary <not....@gmail.com> wrote: > I think I understand the objections to the proposed environment variable > now. I'm branching Rakudo, and attempting my first ever patch, in order to > make handle-specific buffer size possible. Leaving in the env var, as that > still has possible use... > On Apr 2, 2016 8:47 AM, "Tom Browder" <tom.brow...@gmail.com> wrote: > >> On Thursday, March 31, 2016, Elizabeth Mattijsen <l...@dijkmat.nl> wrote: >> > > On 31 Mar 2016, at 14:12, Tom Browder <tom.brow...@gmail.com> wrote: >> ... >> > >> > but I'll put the code on my github account later today. I'm sure it can >> be tweaked, >> > but the gross differences between Perl 6 and Perl 5 doing a very common >> task >> > I think should be seriously investigated by someone familiar with >> > MoarVM >> internals. >> >> Done: >> >> https://github.com/tbrowder/perl6-read-write-tests >> >> > I think jnthn already as synchronous printing (not using libuv) on the >> list of things to do. >> >> I do see that on the list at moarvm.org. >> >> I wonder if it would be worth the effort to try to make a module which >> uses the native call capability to use libc's readline and see if >> there is any significant speed up? >> >> Best, >> >> -Tom >> >
