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!news.glorb.com!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Reserve_Capacity for Unbounded_String? Date: Tue, 24 Jul 2007 19:52:41 -0500 Organization: Jacob's private Usenet server Message-ID: References: <1185134043.892012.217560@n2g2000hse.googlegroups.com> <1185203238.701948.307410@m37g2000prh.googlegroups.com> <46A5B0FE.3060008@obry.net> <46A69136.3010803@obry.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1185324621 21251 69.95.181.76 (25 Jul 2007 00:50:21 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 25 Jul 2007 00:50:21 +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:1145 Date: 2007-07-24T19:52:41-05:00 List-Id: "Pascal Obry" wrote in message news:46A69136.3010803@obry.net... > Randy Brukardt a �crit : > > 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. > > Well Randy, its all too easy to dismiss points like this by saying that > you have not seen a problem with the current implementation and if > somebody show you something wrong in this area then he has to use > something else that Unbounded_String... At least that's the way I'm > reading your message. > > Just try this on your implementation: > > C : constant Character := 'x'; > > U : Unbounded_String; > > for k in 1 .. 5_000_000 loop > U := U & C; > end loop; > > And then test it with GNAT. Of course that is not a real example but > very close to something done in my templates engine. > > You were speaking about performance about checking the preallocated > buffer. My point is that it is not that costly compared to the price of > reallocating a whole string thousands of time. > > Pascal. > > -- > > --|------------------------------------------------------ > --| Pascal Obry Team-Ada Member > --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE > --|------------------------------------------------------ > --| http://www.obry.net > --| "The best way to travel is by means of imagination" > --| > --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595