Re: Reserve_Capacity for Unbounded_String?

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

"Pascal Obry" <pascal@obry.net> wrote in message
news:46A5B0FE.3060008@obry.net...
> Randy Brukardt a �crit :
> > In any case, implementing Reserve_Capacity to do anything (as opposed to
> > being a no-op) in Janus/Ada would require junking the entire existing
> > implementation and starting over. It surely would add overhead (because
> > you'd continually need to check the allocated length against the
"nominal"
> > length). As such, this is something I would fight strongly.
>
> Well this is already done in GNAT for speed performances. If you are
> adding lot of chunk of string into an Unbounded_String it is far too
> costly to reallocate the Unbounded_String buffer each time. This was a
> huge speed penalty for the templates_parser for example. The current
> GNAT implementation is just what users would expect it to be.

Maybe some uninformed users, but not anyone who doesn't add non-existent
requirements to the specs.

Unbounded_String is best used for storage (not calculation) of values. It is
a horrible design for calculation, no matter what schemes you use for the
implementation.

Moreover, I've yet to see an example where the performance of
Unbounded_Strings (allocation-wise) matters. Our spam filter was written
solely using Unbounded_Strings, it does a lot of calculation (normalization
of e-mail) and still the allocation overhead is insignificant. (The
bottleneck is in Index, which does no allocation at all.)

I can imagine that it would be possible to write a program where the
allocation overhead would matter, but such a program would be helped a lot
more by avoiding Unbounded_Strings (and *all* of their allocation overhead)
than by tweaking the implementation of Unbounded_Strings to reduce that
overhead in a few rarely used operations.

So I stand by my original statement. Anyone that depends on the performance
characteristics of a particular implementation (of anything!) is an idiot
and will be burned in the future.

                                              Randy.