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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,794c64d1f9164710 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-02-25 22:46:00 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news.tele.dk!small.news.tele.dk!195.64.68.27!newsgate.cistron.nl!psiuk-p2!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: functions, packages & characters Date: Mon, 25 Feb 2002 15:49:02 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <20020221130715.12738.00000034@mb-bg.aol.com> <3C753C66.8020509@mail.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1014670144 2636 136.170.200.133 (25 Feb 2002 20:49:04 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 25 Feb 2002 20:49:04 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:20441 Date: 2002-02-25T20:49:04+00:00 List-Id: "Randy Brukardt" wrote in message news:u7l4ih2guo0gf6@corp.supernews.com... > > I thought I said that if you make the buffer large enough, it wouldn't > be so slow -- but it also would require a large buffer for many > applications (if it didn't, there would be little reason to use > unbounded strings in the first place). > O.K. I must have misunderstood. Clearly if you pick a buffer size that accommodates *most* of the lines you're likely to read, you'd have no real problem dealing with some small percentage of the cases where you'd have something reallocating more and more memory. > > > I can only comment on the Janus/Ada one (which may not be > representative). It just allocates a string of the correct length for > every operation. That is the easiest implementation (and the one that > GNAT 3.14 uses), but it uses the heap a lot. Improving the performance > of this library has not been a priority, as there isn't any point in > trying to "optimize" it unless you have some real applications using it > that are too slow. Otherwise, you run the risk of making the "average" > application slower. > Interesting. So in the cases where you'd be doing insertions, deletions and so forth, you'd be forcing a reallocation for every operation? Obviously, that could get expensive if you're doing a lot of string manipulation. I could imagine it being a bit more efficient if it allocated memory in blocks to enable some expansion & contraction without having to go back for more every time. > In any case, Ada.Strings.Unbounded is inappropriate for long-running > applications (such as the AdaIC web server), because continued use of > the heap will eventually lead to fragmentation and memory exhaustion > (and decreasing performance in a virtual memory environment). > If the strings you're dealing with require a lot of manipulation this would be the case. I've had apps that deal with a relatively static body of text - you may not know its initial size, but once loaded it might remain stable. Its always important to look at how it gets used and understand what the penalties are for using a given feature. I've used Unbounded_String a lot and never found it to behave poorly in the kinds of apps I've done that way. Of course, most of these didn't really stress test it - they've been pretty straightforward text manipulation things where the ease of use for Unbounded_String outweighed whatever inefficiencies may have been there. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/