"Peter Danford" <pdanford_qed@yahoo.com> wrote in message news:20040603033313.94424.qmail@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