Re: Ann: Natools.Chunked_Strings, beta 1

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 30 Nov 2011 18:11:10 -0600, Randy Brukardt wrote:

> "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魥 (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).

See, the pattern matcher should have the "line end" atom. My pattern
matcher has it.

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

This is very likely. But my concern was not performance, rather the idea of
having long strings. Since long text strings do not exist in "nature"
(:-)), nobody should like to have them.

> To reiterate, premature optimization is the root of all (well, really most) 
> evil.

Yes

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

No. Using unspecialized data structures for special purposes is not a mean
to prevent premature optimization, it is dirty, in some sense weakly typed,
design. A more careful design would possibly bring a better performance,
but that is not the primary concern.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de