On Fri, 24 Feb 2012 00:24:16 +0100, Andrei Alexandrescu
<seewebsiteforem...@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
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.
Andrei
Could we get rid of libc file streams or do we need to share the locks
with C?
