Re: Reserve_Capacity for Unbounded_String?

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

"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). Our spam filter
does operations like this, and as I said earlier, the performance bottleneck
is with Index and with the file I/O operations and not here. (Nor are there
any fragmentation problems that I can detect; the program runs for many days
without issues.)

In any case, I would expect this operation (of making the string longer) to
do a lot of allocations anyway, because the string will need to be expanded
a lot. And any "over"-allocation will be wasteful of memory; for the spam
filter, that would tend to reduce the maximum size of messages that could be
filtered.(Janus/Ada always emphasizes smaller memory usages versus wasting
memory to get better performance.)

Besides, in Janus/Ada, most the alternatives would also do a (under the
covers) "new" and "free". We do try to optimize those out, but by default

             Var : String := Some_Value & 'x';

would generate three allocations and deallocations. The optimizer probably
would get rid of the descriptors or allocate them statically, but the object
Var probably would end up in the heap.

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 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.

                        Randy.