Re: Ann: Natools.Chunked_Strings, beta 1

[Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org>]

On 12/01/2011 03:57 AM, Natasha Kerensikova wrote:
>
> 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.

First let me say that for fun or as a learning experience (1. and 2. from the 
previous post) are perfectly valid reasons to be doing this, and no further 
justification is needed. Doing it when 1. and 2. do not apply, that is, when the 
sole reason for writing the software is to get something done (such as a SW 
development job), is when inability to meet timing requirements (3.) comes into 
play. If you can meet your timing requirements with off-the-shelf components, 
then unnecessarily creating an optimized component delays completion of the 
project and increases the cost.

So all my following discussion will only apply to cases where 1. or 2. do not 
apply (which is to say, not to your project).

Literature and experience are filled with examples where "serious reasons to 
believe" turned out to be wrong, which is how the adage about premature 
optimization came to be.

(You might be interested in "Ada Outperforms Assembly", a classic case where 
what experts "knew" about SW performance turned out to be wrong:

http://www.seas.gwu.edu/~adagroup/sigada-website/lawlis.html)

Finally, a performance bottleneck is not necessarily a bad thing. It is a 
performance bottleneck that prevents meeting timing requirements that justifies 
expending effort on optimization.

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

I'm not saying that 3. will never occur. I'm saying that until you've done it 
without the optimization, measured it, and shown that it fails to meet timing 
requirements, you don't know that 3. applies and are not (yet) justified in 
optimizing.

Clearly there is a point where performance is good enough: the point where 
timing requirements are met. Effort expended on improving performance once the 
timing requirements are met is wasted effort.

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

The evil of premature optimization is the waste of effort when the optimization 
is unnecessary.

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

We have timing requirements that our SW meets. I'm not saying that we have never 
needed to take steps to improve the performance of the SW, just that the use of 
Unbounded_Strings has never been the reason for not meeting our requirements.

-- 
Jeff Carter
"I wave my private parts at your aunties."
Monty Python & the Holy Grail
13