From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,
	PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,64b29dfa2220a59f
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!feeder.news-service.com!feeder1.cambrium.nl!feed.tweaknews.nl!amsnews11.chello.com!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Reserve_Capacity for Unbounded_String?
Date: Tue, 24 Jul 2007 13:58:51 -0500
Organization: Jacob's private Usenet server
Message-ID: <f85i0u$jsl$1@jacob-sparre.dk>
References: <1185134043.892012.217560@n2g2000hse.googlegroups.com>
 <1185203238.701948.307410@m37g2000prh.googlegroups.com>
 <f83ish$p8o$1@jacob-sparre.dk> <46A5B0FE.3060008@obry.net>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: jacob-sparre.dk 1185303391 20373 69.95.181.76 (24 Jul 2007 18:56:31
 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Tue, 24 Jul 2007 18:56:31 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
Xref: g2news2.google.com comp.lang.ada:1130
Date: 2007-07-24T13:58:51-05:00
List-Id: <comp.lang.ada>

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