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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM 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 m6mr2416615pbj.4.1322737123687; Thu, 01 Dec 2011 02:58:43 -0800 (PST) Path: lh20ni50753pbb.0!nntp.google.com!news2.google.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: Ann: Natools.Chunked_Strings, beta 1 Date: Thu, 1 Dec 2011 10:57:23 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <4ed4fc37$0$2537$ba4acef3@reader.news.orange.fr> Mime-Version: 1.0 Injection-Date: Thu, 1 Dec 2011 10:57:23 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="Mda950WjNwNLAFOE7yJXQw"; logging-data="18435"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+hCHLijCSegzRUCK+ouN2R" User-Agent: slrn/0.9.9p1 (FreeBSD) Cancel-Lock: sha1:P7pzWWu2JAv4yUNUA/fa5RWGJO4= Xref: news2.google.com comp.lang.ada:14773 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 2011-12-01T10:57:23+00:00 List-Id: Hello, On 2011-11-30, Jeffrey Carter 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