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
operation.
>> 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
> changes.
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.
Markus