Bug 11810 – std.stdio.byLine/readln performance is very bad

Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P2
Component
phobos
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-12-24T04:34:00Z
Last change time
2016-05-30T15:54:18Z
Assigned to
nobody
Creator
peter.alexander.au

Attachments

IDFilenameSummaryContent-TypeSize
1305bylinefast.dbyLineFast with small changesapplication/octet-stream6051

Comments

Comment #0 by peter.alexander.au — 2013-12-24T04:34:29Z
std.stdio.readln (and hence byLine) use repeated calls to fgetc() to find the new line characters. This is a very inefficient way to read files (lots of per-byte overhead). I have a version of byLine that reads the files in 4kb chunks and then does the new line search. It is 6 times faster than byLine on my machine on a 10MB file (OSX 10.8.5, x64 2GHz MacBook).
Comment #1 by dejan.lekic — 2013-12-24T04:42:03Z
It has been discussed on IRC hundreds of times and we all agreed that if developer wants performance (s)he would read page-size chunks. That is why we have byChunk(size_t) in std.stdio, I believe. :)
Comment #2 by peter.alexander.au — 2013-12-24T05:27:14Z
(In reply to comment #1) > It has been discussed on IRC hundreds of times and we all agreed that if > developer wants performance (s)he would read page-size chunks. That is why we > have byChunk(size_t) in std.stdio, I believe. :) OK, but: 1. It's non-trivial to implement byLine on top of byChunk. 2. Why would you want byLine to be slow? I'm not seeing the advantage of keeping byLine as it is. Fixing it doesn't change the API and has no downsides other than requiring a bit extra memory for the buffer.
Comment #3 by bearophile_hugs — 2013-12-24T10:08:13Z
(In reply to comment #1) > It has been discussed on IRC hundreds of times and we all agreed that if > developer wants performance (s)he would read page-size chunks. That is why we > have byChunk(size_t) in std.stdio, I believe. :) This is not acceptable. byLine is a very commonly used function (far more than byChunk in script-like D programs) and it should be sufficiently fast.
Comment #4 by lomereiter — 2013-12-24T10:47:16Z
Comment #5 by bearophile_hugs — 2013-12-24T13:11:31Z
Created attachment 1305 byLineFast with small changes
Comment #6 by hsteoh — 2013-12-26T14:23:27Z
The whole point of byLine is to be a convenient API for user code to read lines from a file. It should not be constrained to using fgetc() just because we can't predict line length in advance. It should be built on top of a buffering mechanism (maybe byChunk) so that it offers good performance to a very commonly-used user operation. I highly recommend Peter Alexander to submit the improved byLine implementation to Phobos.
Comment #7 by nick — 2014-02-28T08:55:17Z
(In reply to comment #5) > Created an attachment (id=1305) [details] > byLineFast with small changes BTW I'm working on porting this to std.stdio.byLine, I'll submit a PR when finished.
Comment #8 by nick — 2014-04-10T15:51:02Z
Here's as far as I got: https://github.com/ntrel/phobos/commits/byLine-fast This is faster than standard byLine on my Windows box iff std.utf.validate is not called for each line. To be honest, I'm not sure whether std.stdio.readln is doing UTF validation or not. readln has different implementations so performance of standard byLine varies by platform. I'm not sure whether this would be accepted as a PR. One issue is that when using stdin you couldn't input just one line at a time anymore.
Comment #9 by bearophile_hugs — 2014-04-10T16:52:15Z
(In reply to Nick Treleaven from comment #8) > I'm not sure whether this would be accepted as a PR. There is also a need for benchmarks, comparing it to the Phobos byLine, to the byLineFast that is in attach, and to equivalent Python2.x and Java code.
Comment #10 by andrei — 2015-03-22T07:18:49Z
Comment #11 by andrei — 2015-03-22T07:19:23Z