From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2004-08-25 03:26:25
Ralf W. Grosse-Kunstleve wrote:
> --- Markus_Schöpflin <markus.schoepflin_at_[hidden]> wrote:
>> I believe process_jam_log would eventually have finished, I you would
>> have been patient enough. (Maybe next year or so... :-) )
> Oh, I didn't think processing a few log files with a C++ program could
> take more than 75 minutes?!
The program appends many single chars to strings in several places and this
is a real performance killer in the std library implementation available on
this platform. It looks like it does a realloc and copy for every append
>> I checked in a performance patch for process_jam_log yesterday, do you
>> know if your version already has that patch included?
> I was using revision 1.31. A cvs update right now didn't lead to any
That revision has the patch included.
>> AFAICT, the patch is not enough to let process_jam_log complete in a
>> reasonable amount of time on that platform for a full regression run,
>> but I got a fives times speed-up when processing smaller parts of the
>> regression log file.
> OK, next time I'll wait a little longer.
>> The workaround I'm currently using is to use a binary built by
>> g++-3.4.1, this at least enables me to run the regression tests for
>> that platform.
>> Apart from that, the regression runs for test_read_write_mutex don't
>> hang on my platform currently, they abort with an error. (see
>> http://tinyurl.com/4j7dd )
> Hm, if it works better (kind of) for you with the latest compiler maybe
> I should stop running the tests here... All I care about personally is
> Boost.Python and that works just fine.
Which doesn't work at all here. I have a python installation which up to
now, I was not able to successfully use with the boost regression runs.
Therefore it might make sense if you continue running the regression tests,
at least for python.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk