Re: Reserve_Capacity for Unbounded_String?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wccr6mx5pz0.fsf@shell01.TheWorld.com...
>> "Randy Brukardt" <randy@rrsoftware.com> writes:
> ...
>> > For Janus/Ada, Unbounded_String is just a controlled wrapper around
> "access
>> > String"; in particular, the length is the length of the item
>> > allocated.
>>
>> Are you saying that:
>>
>>     for I in 1..N loop
>>         Append (Some_Unbounded_String, 'x');
>>
>> causes a free and a "new" and a copy every time around the loop?
>
> Yup; I just checked the code to make sure. Moreover, I have yet to see an
> real example where the performance difference would matter that much (Free
> and new aren't that expensive relative to the alternatives).

It's the copy I'm wondering about, not the new and free so much.
To append N characters to an unb string requires quadratic copying
(copying a char N**2 / 2 times).

If you double the allocation every time, it's amortized linear.
Yes, you waste some space that way.

> If performance is a real issue, you'd have to write your own code to do the
> actual operations you want; for instance, in your example
> To_Unbounded_String (Some_Unbounded_String, (1..N => 'x')); would be a lot
> faster ...

Yes, but that's just an example.  The real example is where you're
reading characters one-by-one from somewhere, and you don't know how
many there will be, and you want to append some of them to a string.

>...on any compiler (far fewer calls to a library; even if there is no
> allocation, there still will be overhead checks for bounds and the like).
> The examples where an alternative implementation of Unbounded_Strings would
> make a significant difference such that the application was fast enough with
> it and not fast enough without it have to be extremely rare.

Fair enough.  Real-world measurements beat theoretical reasoning.  ;-)

- Bob