Front page | perl.perl5.porters |
Postings from October 2014
On Mon, Oct 13, 2014 at 1:16 AM, H.Merijn Brand <h.m.brand@xs4all.nl> wrote: > On Sun, 12 Oct 2014 20:30:34 -0500, "Craig A. Berry" > <craig.a.berry@gmail.com> wrote: > >> On Sun, Oct 12, 2014 at 7:53 PM, Father Chrysostomos via RT >> <perlbug-followup@perl.org> wrote: >> >> >> I'd considered reading perl source with a buffer size of 4096 to be a >> >> bug in itself. It seems not to be perlio's fault. Using the -DP debug option shows that an 8K perlio buffer (or I guess really it's a crlf buffer not perlio since this is Windows) gets filled and depleted 5 times when reading in the 40,986-byte warnings.pm, which sounds about right: c:\perlgit>.\perl -Ilib -DP -e "use warnings;" 2>sv_gets_debug.txt c:\perlgit>find "cnt=8191" sv_gets_debug.txt ---------- SV_GETS_DEBUG.TXT Screamer: after getc, ptr=2856305, cnt=8191 Screamer: after getc, ptr=2856305, cnt=8191 Screamer: after getc, ptr=2856305, cnt=8191 Screamer: after getc, ptr=2856305, cnt=8191 Screamer: after getc, ptr=2856305, cnt=8191 I assume here that 8192 bytes are read and the getc consumes one so the 8191 is how many bytes are left. I could be missing something as sv_gets() and add_filter() and friends are pretty hairy, but it looks as though the 4K ReadFile operations that bulk88 originally reported are something the CRT does with read() rather than anything that happens within Perl. Don't know if a setvbuf() or something could improve on that. To be clear, I'm speculating on what could be sub-optimal about fundamental read operations and am not talking about the patches in the ticket, which seem like reasonable workarounds.Thread Previous | Thread Next