Re: Ada bench : count words

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 22 Mar 2005 16:48:13 +0000, Marius Amado Alves wrote:

>> Get_Line does one extra line scan. So it will be inherently slower. 
>> Then it would not take any advantage of having Buffer if lines are 
>> shorter than 4K.
> 
> I'm not sure I understand. An extra scan (I assume for EOL) in addition 
> to what?

To parse the line. Get_Line scans some n-th buffer attached to the file and
copies bytes from there into your n+1th buffer until it meets EOL. I
suppose under VMS it could be otherwise, but we have what we deserve: UNIX
and Windows. After that you rescan these bytes again. This means that each
byte will be touched n+1 times.

> I don't understand why Get_Line has to be slower. I understand how a 
> naive, non-buffered, implementation can be slower. But at least when 
> reading from standard input the implementation should buffer, or cache, 
> the data, on a buffer of Item'Size or greater, and remember the 
> positions, and never read again.

Only if Get_Line were a function returning a slice referring to a system
buffer that had multiple segments with reference counting ... Forget it
(:-))

BTW, I think that this challenge is wrong because it does not filter I/O
issue out. In real-life applications it is not Text_IO (or its equivalent
in any other language) which is the bottleneck. Text_IO could be 10 times
slower and still impose no or little problems, because string processing in
the true sense, is usually 1000 times slower.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de