Re: Reserve_Capacity for Unbounded_String?

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

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcctzrtrzhz.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
> > 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).

True enough, but copying is extremely cheap relative to other operations. It
could only matter if N is extremely large, and that won't work in Janus/Ada
anyway (because Ada.Strings.Unbounded is broken in that it depends on type
Integer, which is 16-bit in Janus/Ada for historical reasons; if you want
really big strings in Janus/Ada you have to declare them yourself. I don't
much like this situation, but it is not practically fixable.)

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

Quadratic allocation maximizes heap fragmentation (a major issue for small
heaps, and a performance trap for all), and I no longer use it anywhere for
that reason. It also wastes huge amounts of space for long strings. I could
see using a scheme where you rounded up to the nearest 16 (or some similar
number) bytes (as the storage pool is likely to do something like that
anyway); that would catch the long-hanging fruit (i.e. appending lots of
single characters) without too much impact in terms of memory. But anything
further would have nasty memory use effects on programs with a lot of
unbounded strings. And doing that would cost extra overhead on every string
operation; most of them for which there would be no gain.

I still don't think it is worth it, but obviously a customer example could
change my mind.

                              Randy.