Re: functions, packages & characters

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"Randy Brukardt" <randy@rrsoftware.com> 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/