Re: Ann: Natools.Chunked_Strings, beta 1

[Natasha Kerensikova <lithiumcat@gmail.com>]

Hello,

On 2011-11-30, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 11/30/2011 06:08 AM, Natasha Kerensikova wrote:
>>
>> [An implementation optimized for appending should have better performance for
>> that use and GNAT's Unbounded_String uses a contiguous array] Combined with
>> the fact I use GNAT is enough (for me) to justify writing
>> Natools.Chunked_Strings.
>
> Justifications for rewriting Unbounded_Strings are
>
> 1. For fun
> 2. As a learning experience
> 3. You have timing requirements you can't otherwise meet.

1. and 2. were pre-conditions here. Among all the mini-projects that
meet 1. and 2., I used 3. or suspicion of 3. to choose. That's how it is
relevant.

> 3. does not appear to be the case here; you're planning to write
> something, but you have yet to demonstrate that Unbounded_Strings
> isn't suitable for its timing requirements.

I have serious reasons to believe that 3. will probably happen. While
the Ada project with requirements is not yet complete (though already
written, for the most part), it is very similar to a C project I already
wrote. And for that C project, the repeated dynamic array resizes
triggered by repeated string append are demonstrated to be the
performance bottleneck, and therefore the next thing to work on should
performance be improved.

I agree that it might turn out that the Ada project has other
performance issues. But saying that 3. will *never* be a problem is
saying that either there is a point where performance is "good enough"
and that this point is reached sooner than Unbounded_String performance
issue, or that there is some fundamental unavoidable performance hit in
Ada that does not exist in C.

It stills seems to me fair to assume the latter is wrong, and the former
is a suspiciously strong assumption on my project compared to what I
disclosed about it.

> So you're doing it for 1.
> or 2. Doing it for 3. when you haven't demonstrated 3. is premature
> optimization, AKA the root of all evil.

I don't need a hard demonstration with numbers and benchmarks to know
the weak points of my designs. Especially when I do have them for a very
similar design. And unless there is a "good enough" line or an expected
performance flaw in Ada, I'm certain that Unbounded_String append
performance *will* be an issue.

Moreover, I strongly doubt any evil can come from these performance
considerations. A mere package cannot do any evil. The premature
optimization that is actually at the root of any evil is when
unwarranted performance consideration creep up to the design phase. As I
said above, my considerations are far from being unwarranted, and the
only design choice that could be qualified as premature optimization is
the use of String_Accumulator interface (rather than naive direct calls
to Ada.String.Unbounded subprograms). I would be happy to hear arguments
for or against that choice.

> FWIW, we have a large, soft-real-time system that makes extensive use of 
> Unbounded_Strings, and have no problem meeting our timing requirements.

Then I guess you are lucky enough to have a "good enough" line (and to
be on the good side of it).


Natasha