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.9 required=5.0 tests=BAYES_00 autolearn=ham
	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 11:36:49 PST
Path: 
 archiver1.google.com!news1.google.com!sn-xit-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: functions, packages & characters
Date: Mon, 25 Feb 2002 13:37:51 -0600
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <u7l4ih2guo0gf6@corp.supernews.com>
References: <mailman.1014282062.23400.comp.lang.ada@ada.eu.org>
 <20020221130715.12738.00000034@mb-bg.aol.com> <3C753C66.8020509@mail.com>
 <u7b1g6cooeo49@corp.supernews.com> <u7b4d1bmd1f7ef@corp.supernews.com>
 <u7bcro6je1h519@corp.supernews.com> <a55iip$4s7$1@nh.pace.co.uk>
X-Newsreader: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500
X-Complaints-To: newsabuse@supernews.com
Xref: archiver1.google.com comp.lang.ada:20390
Date: 2002-02-25T13:37:51-06:00
List-Id: <comp.lang.ada>

Marin David Condic wrote in message ...
>I'm curious about why you think this would be slow? (I may have to
build a
>small chunk of code and time it! :-) In most applications I can think
of,
>you can usually set some kind of arbitrary max sized buffer (the size
of
>"Line" below...) that is going to accommodate most lines in your
average
>text file. (Usually, you have some notion of the kinds of text files
you
>want to process, right?) The presumption is that you might infrequently
have
>to go 'round the loop a second (or third or fourth) time to glom onto
the
>rest of the line, so for 99% (or some high percentage of the time)
you're
>just doing a single Get_Line (is that inefficient?) and a single Append
to
>an unbounded string (again, is that necessarily inefficient?)

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

>I've never looked into the underlying implementation of
Unbounded_String in
>any Ada compiler, so I have no clue as to how naturally (in)efficient
they
>may be. I'm guessing a typical implementation is going to be some
collection
>of memory blocks strung together with pointers and some counters. Would
>"Append" require some huge overhead?


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.

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

                Randy.