Re: GNAT/Ada95 Streams Performance Issue

[Larry Hazel <lhhazel@otelco.net>]

Waldek Hebisch wrote:
> Warren W. Gay VE3WWG (ve3wwg@cogeco.ca) wrote:
> : 3. The individual characters that make up Msg are written
> :      out to stream S, using individual calls to Character'Write.
> 
> : Step # 3 is the performance killer.
> 
> : To help in this regard, APQ 1.2 (not released yet) now supports
> : two new functions for performance reasons:
> 
> :       String_Output to substitute for String'Output
> :       String_Input to substitute for String'Input
> 
> : These routines deal with the array of characters as
> : one block of data.
> 
> : But this is really just a patch over part of a much
> : larger problem.
> 
> : How have other people dealt with this type of streams
> : performance issue?  Or do people generally avoid
> : streams when performance is important?
> 
> Well, I just toyed with a simple cat program:
> 
>         loop
>                 Ada.Text_IO.Get_Line( Line, Last );
>                 Ada.Text_IO.Put_Line( Line(1..Last) );
>         end loop;
> 
> Using GNAT (gcc 3.1.1), I get very bad performance (about 10 MB/s, raw 
> system calls (in C) give 450MB/s). I looked at the sources, and while 
> Put_Line essentialy outputs the block (it makes a copy and modifies it 
> slightly) Get_Line works with single characters. The problem is that to 
> cooperate nicely with C Ada has to go trough C stdio interface. Since Ada 
> and C semantics differ Ada cannot use C block input. The problem is magnified 
> becouse each C stdio function performs locking. 
> 
Somewhere around 1990, I wrote a simple file copy program using Sequential_IO on 
files of bytes.
This was using the Verdix Ada 83 compiler on a Sun.  I did this as a test 
because C people kept telling me how slow Ada was.  I wanted to see for myself. 
    It was consistently faster than the unix cp command.  I suspect there was a 
lot of buffering going on behind the scenes.

Larry