Re: Ann: Natools.Chunked_Strings, beta 1

["Randy Brukardt" <randy@rrsoftware.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ouubrb3trn06$.1jl5q3ausoy2v.dlg@40tude.net...
> On Wed, 30 Nov 2011 11:39:30 +0100, Yannick Duch�ne (Hibou57) wrote:
>
>> By the way, I feel the original message is based on erroneous assumptions
>> about implementations of Ada.Strings.Unbounded. Nothing in the RM 
>> requires
>> an implementations to use a single array for unbounded strings, and on 
>> the
>> opposite, it says `type Unbounded_String is private;`.
>
> I false assumption is IMO that strings are large and need to be 
> manipulated
> as a whole, e.g. pieces substituted etc.
>
> In each such case the user should consider:
>
> 1. maybe the pattern he uses is wrong (e.g. poor parsing techniques
> splitting and merging strings physically)
>
> 2. maybe string is an inappropriate data structure and something like text
> buffer should be used instead.
>
> It is C where everything is char*, not Ada.

I don't agree, for a number of reasons:

(1) The Trash-Finder spam filter uses an "append-all" pattern to handling 
text and html filtering (along with a few replacements). That's mainly 
because it is best to ignore line-breaks in such matching. I could have 
invented a different data-structure for that use, but it would have just 
meant more work (especially to recreate the string pattern-matching 
operations, which are used extensively).
(2) I worried about the performance of this code, especially in the 
"service" version of TF -- but there is no evidence that using unbounded 
strings and all of that unstructured heap makes any real difference at all, 
even when TF runs for months between restarts.
(3) The only thing that ever took significant time is the actual pattern 
matching, and a few optimizations to that code eliminated the problem. 
(Obviously, it helps that I have my own compiler and run-time to tweak, but 
the optimizations make sense in general, they don't add much code and reduce 
the runtime a lot in some common circumstances.)

To reiterate, premature optimization is the root of all (well, really most) 
evil. That includes making generalizations about the use of data structures! 
Spending a lot of time writing some other data structure when a predefined 
one will do is just plain silly.

                         Randy.