[boost] Re: Re: Re: Thread lib (good reason for static)

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-06-03 02:14:20

"Peter Danford" <pdanford_qed_at_[hidden]> wrote in message
news:20040603033313.94424.qmail_at_web60604.mail.yahoo.com...
> I have already tried using the profiler mentioned below. It is a very
slick thing. But it was not that useful on a complete run (that normally
takes 20 hours or so) because the instrumented version takes orders of
magnitude longer to run. In fact, after about an hour of running the
instrumented version, the run was not even past the preliminary
initialization stage :(.

If you could just leave it running long enough to perform the "real work"
for some time (leave it running overnight perhaps) I guess you could abort
it and take a look at the data collected so far. If you could do this once
for the dynamic-linked version once for the static linked version, you
should be able to see any percentual differences between times spent in the
various Boost.Thread functions.

Perhaps you could leave the main modules uninstrumented, and just prepare
the Boost.Thread stuff for instrumentation to avoid the excessive startup
time. This is just pure speculation - I don't even know if this is possible.

>
> That being said, I think there is surely a lot of room for more clever and
faster code, but it simply is computationally intensive by nature....

The computationally intensive stuff should be unrelated to Boost.Thread
performance. Actually I have a hard time finding out why there should be a
difference at all unless you create a lot of temporary threads all the time
(causing locks in DllMain's THREAD_ATTACH / DETACH notifications IIRC).

// Johan