Ralf W. Grosse-Kunstleve wrote:
--- Markus_Schöpflin <markus.schoepflin@comsoft.de> 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