comp.lang.ada
 help / color / mirror / Atom feed
From: Ted Dennison <dennison@telepath.com>
Subject: Re: Performance and Thread Safety of the Booch Components
Date: 2000/04/21
Date: 2000-04-21T00:00:00+00:00	[thread overview]
Message-ID: <39006687.9341ACAA@telepath.com> (raw)
In-Reply-To: 1e9flrw.13c8d0t190e9v6N%herwin@gmu.edu

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






  reply	other threads:[~2000-04-21  0:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-04-21  0:00 Performance and Thread Safety of the Booch Components Harry Erwin
2000-04-21  0:00 ` Ted Dennison [this message]
2000-04-22  0:00   ` Simon Wright
2000-04-24  0:00     ` Ted Dennison
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox