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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5642b5e0552e165e X-Google-Attributes: gid103376,public From: Ted Dennison Subject: Re: Performance and Thread Safety of the Booch Components Date: 2000/04/21 Message-ID: <39006687.9341ACAA@telepath.com>#1/1 X-Deja-AN: 613966635 Content-Transfer-Encoding: 7bit References: <1e9flrw.13c8d0t190e9v6N%herwin@gmu.edu> X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-Complaints-To: Abuse Role , We Care X-Trace: newshog.newsread.com 956327245 216.14.8.120 (Fri, 21 Apr 2000 10:27:25 EDT) Organization: Telepath Systems (telepath.com) MIME-Version: 1.0 NNTP-Posting-Date: Fri, 21 Apr 2000 10:27:25 EDT Newsgroups: comp.lang.ada Date: 2000-04-21T00:00:00+00:00 List-Id: Harry Erwin wrote: > Experience with the STL in C++ has shown that the standard container > classes and associated algorithms degrade performance severely unless a > significant level of optimization is turned on. This is in part due to > the number of temporary objects and function calls that get generated. ... > The Booch components appear to be generally exception-safe and > exception-neutral. Are there any issues known that I should be aware > of?--other than one esoteric bug involving copying between queues of > different types that I've already reported. I don't think they really have been highly tuned for performance. As an example, we were using doing multiple lookups using a map object in a loop that gets executed at 60Hz for a simulator. Performance was terrible even on GreenHills' highest optimization levels, so I looked at it with a subprogram-level performance analyzer. It turned out that even the *bounded* maps (which you'd figure wouldn't do dynamic allocation) were dynamicly allocating an iterator every lookup. I fixed that, then found that it was still quite slow due to the fact that the (20 or so byte) result of the lookup was getting passed as a "return" value through 3 successive function's return calls. That resulted in each object in the map getting copied 4 times at 60Hz. You'd think that there'd be some way for the compiler to optimize that down to one copy at the assignemt on the outside, but I couldn't find it. So I just wrote a procedure version and that did the trick. I submitted all these changes to Simon Wright for possible incorporation into the official components, but of course this is only Maps. I'm not trying to rag on Simon here, or those who came before him. I'm just pointing out that Booch is a volunteer effort. Improvements in functionality come when someone with the proper tools takes an interest in it. If you have interest in high-performance components, and you have access to a execution profiler, I'd encourage you to use the components. Just be prepared to have to make a couple of twiddles here and there (and please send them back to Simon, so the next person won't have to do it too). -- T.E.D. Home - mailto:dennison@telepath.com Work - mailto:dennison@ssd.fsi.com WWW - http://www.telepath.com/dennison/Ted/TED.html ICQ - 10545591