From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a65bb7bde679ed1d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.36.6 with SMTP id m6mr4427548pbj.4.1322766515990; Thu, 01 Dec 2011 11:08:35 -0800 (PST) Path: lh20ni53118pbb.0!nntp.google.com!news1.google.com!goblin2!goblin1!goblin.stu.neva.ru!news.tornevall.net!.POSTED!not-for-mail From: Jeffrey Carter Newsgroups: comp.lang.ada Subject: Re: Ann: Natools.Chunked_Strings, beta 1 Date: Thu, 01 Dec 2011 12:07:09 -0700 Organization: TornevallNET - http://news.tornevall.net Message-ID: References: <4ed4fc37$0$2537$ba4acef3@reader.news.orange.fr> NNTP-Posting-Host: 1e207585b9eed9cd5bfc1e982b1773c2 Mime-Version: 1.0 X-Trace: 5479dccca59355bdcb081006a3854cd0 X-Complaints-To: abuse@tornevall.net User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 X-Complaints-Language: Spoken language is english or swedish - NOT ITALIAN, FRENCH, GERMAN OR ANY OTHER LANGUAGE! In-Reply-To: X-UserIDNumber: 1738 X-Validate-Post: http://news.tornevall.net/validate.php?trace=5479dccca59355bdcb081006a3854cd0 X-Complaints-Italiano: Non abbiamo padronanza della lingua italiana - se mandate una email scrivete solo in Inglese, grazie X-Posting-User: 0243687135df8c4b260dd4a9a93c79bd Xref: news1.google.com comp.lang.ada:19291 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2011-12-01T12:07:09-07:00 List-Id: 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