Re: Performance of the Streams 'Read and 'Write

["Randy Brukardt" <randy@rrsoftware.com>]

"Gautier write-only" <gautier_niouzes@hotmail.com> wrote in message 
news:715d78f4-9b01-4598-88c1-6fc202983bae@p35g2000yqh.googlegroups.com...
> On 30 Okt., 04:36, Georg Bauhaus <rm-host.bauh...@maps.futureapps.de>:
>
>> I finally thought that the above procedures are faster than 'Read
>> or 'Write because the latter are defined in terms of stream elements:
>> When there is a composite object like b : Buffer and you
>> 'Write it, then for each component of b the corresponding 'Write
>> is called. This then writes stream elements, probably
>> calling Stream_IO.Write or some such in the end.
>> So Write from above appears closer to writing bulk loads
>> of stream elements than a bulk load of 'Writes can be.
>
> Sure, it is the safe way: write records field by field, arrays element
> by element (that recursively). The compiler avoids problems with non-
> packed data. Nothing against that. The general case is well done,
> fine. But the compiler could have a look a the type left to the
> attribute and in such a case (an array of Unsigned_8, or a String)
> say: "Gee! that type Buffer is coincidentally the same as
> Stream_Element_Array, then I take the shortcut to generate the code to
> write the whole buffer and, this time, not the code to write it
> element by element".

IMHO, Ada compilers should do that. (There's specifically a permission to do 
this optimization in Ada 2005: 13.13.2(56/2).) That's an intergral part of 
the stream attribute implementation on Janus/Ada. (Disclaimer: the entire 
stream attribute implementation on Janus/Ada doesn't work right, quite 
probably because it is too complicated. So perhaps there is a reason that 
other Ada compilers don't do that. :-) Note, however, that it is pretty rare 
that you could actually do that (only about 15% of the composite types I've 
seen in Janus/Ada would qualify). So I'm not surprised that implementers 
have left that capability out in favor of things that happen more often.

                             Randy.