Re: Reserve_Capacity for Unbounded_String?

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

"Adam Beneschan" <adam@irvine.com> wrote in message
news:1185203238.701948.307410@m37g2000prh.googlegroups.com...
...
> > Is this a reasonable approach if performance is of concern?
>
> I sure wouldn't count on this.

I second (or is that "third") Adam and Jeff's comments.

For Janus/Ada, Unbounded_String is just a controlled wrapper around "access
String"; in particular, the length is the length of the item allocated. The
code you have would just cause an extra allocation/deallocation without any
corresponding benefit (and it might even cause additional fragmentation and
slow the program down).

In general, you cannot depend on the performance of the predefined packages;
you can presume that implementations have done a decent job for their
target, but that is about all. (The containers are a bit of an exception, in
that there are performance requirements on them; but those requirements are
vague enough to be pretty meaningless for average-sized containers.)

I usually recommend to use the predefined packages as necessary in your
application, and avoid worrying about performance of them. If it turns out
that there is a performance problem, and that problem is with the one of the
predefined packages, then it makes sense to replace the offending package
with something custom-written to match the problem at hand. (In this case,
just using type String and doing your own storage management would seem to
be appropriate.)

For things like Unbounded_Strings (and the Containers), the main value is to
let the package do the memory management (meaning that you have well-tested
memory management that won't leak or break). Trying to take over some of
that is suspicious (that's true for Reserve_Capacity in the containers as
well), because it is easy to get it wrong and cause *worse* performance.

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.

                                 Randy.