|
|
Boost Testing : |
From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2007-10-23 10:36:08
Rene Rivera wrote:
> Markus Schöpflin wrote:
>> Rene Rivera wrote:
>>> Markus Schöpflin wrote:
>> [...]
>>
>>>> Rene,
>>>>
>>>> it looks like your changes didn't help to speed up the process. In the
>>>> contrary, the update cycle now takes more than 6 hours, AFAICT. For
>>>> example, the last update of the trunk results has been at 02:37:35 UTC, the
>>>> current time is 09:56:52 UTC.
>>>>
>>>> Could you please check whether something is amiss?
>>> My local times have the cycle at about 3.5 hours now, not much of an
>>> improvement :-( What you are observing though is misleading. You have to
>>> look at the difference between the release results I post to see the
>>> real interval. So if you only look at the trunk timestamps you'll need
>>> to divide by 2.
>> I see, so the update goes like this:
>>
>> while (true):
>> update trunk results
>> update release results
>
> more like...
>
> while(true):
> generate & publish trunk results
> test trunk
> generate & publish trunk results
> test release
>
> And Beman likely does the inverse of that :-)
Wouldn't it make sense to not run tests on the machine where the results
are generated?
>> Forgive my (probably very naive) question, but why is it actually taking
>> that long to generate the results? After all, it's just parsing through a
>> few log files and generating a number of HTML pages. ;-)
>
> It *could* be fast... If the report generation just wasn't written in
> XSL ;-) One rather slow part is packaging the results up for upload, as
> it takes a fair amount of CPU to zip+bzip2 1.2G of HTML, and then upload
> 130M.
Are you using --fast for zipping the files? This can make a real
difference, both in terms of speed and - unfortunately - also in terms of
size. But I think it would be worth a try if you don't use it already.
> Keep you hopes up though, there's one more change I can do (this
> time to regression.py) that will shorten things a little bit more. But
> if anyone has some brilliant ideas as to how to make the result
> processing faster don't hesitate to implement them.
The most obvious would be not to use XSL, but this has been discussed in
the past already, IIRC.
Markus