A file reading benchmark
dawg at dawgfoto.de
Thu Feb 23 15:46:05 PST 2012
On Fri, 24 Feb 2012 00:24:16 +0100, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> 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
>>> 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
>> 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.
Could we get rid of libc file streams or do we need to share the locks
More information about the Digitalmars-d