A file reading benchmark

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Feb 23 15:24:16 PST 2012

On 2/23/12 3:40 PM, Martin Nowak wrote:
>> On my machine (Mac OSX Lion), the Python code clocks around 1.2
>> seconds and the D code at a whopping 9.3 seconds. I looked around
>> where the problem lies and sure enough the issue was with a slow loop
>> in the generic I/O implementation of readln. The commit
>> https://github.com/D-Programming-Language/phobos/commit/94b21d38d16e075d7c44b53015eb1113854424d0
>> brings the speed of the test to 2.1 seconds. We could and should
>> reduce that further with taking buffering in our own hands, but for
>> now this is a good low-hanging fruit to pick.
> Nice, I just got shocked yesterday by seeing that we call fgetc for
> every char,
> those are usually macros and as we already maintain the per system
> *_unlocked
> functions we might probably use the macro expansions.

Yah, feel free to work opportunistically on this if you find the time. 
However, I think long-term we want to give byLine() the freedom of doing 
its own buffering.


More information about the Digitalmars-d mailing list