|
|
Boost Testing : |
Subject: Re: [Boost-testing] Trunk testing (general) and MSVC11
From: Christoph Macheiner (christoph.macheiner_at_[hidden])
Date: 2012-08-24 12:46:29
"Beman Dawes" <bdawes_at_[hidden]> wrote in message
news:CAAygHNNbEO+qSqvOfeFSpdxVxGL2RF19-9h5MaW1YNLs-5Q51w_at_mail.gmail.com...
> On Thu, Aug 23, 2012 at 12:39 PM, Richard Webb
> <richard.webb_at_[hidden]> wrote:
>>
>>>
>>> Hum... Something must be burning unnecessary disk space. Do you have
>>> an indication what is chewing up all that space?
>>>
>>
>>
>> Lots of large .obj files, and lots of (sometimes even larger) .pdb files.
>
> Is it really necessary to retain these files?
No, the .obj could be deleted after the build and before/after the test run.
The .pdb should be kept in case of a crash/hang to be able to debug or
analyze a dump. For successful tests, the .pdb could be deleted (along with
the rest of the build output). That would reduce the footprint dramatically.
>> (and some of the temp files are *large*. e.g. i see obj files for the
>> xpressive tests that are as much as 70 megabytes each).
>
> Ouch! Eric?
In principle, see above. As for the object size, not sure if there is
anything really that can be done (but I have to await my first successful
test run before I can say anything).
>>> What are the space and time resources other testers are committing? It
>>> would be useful to know if something has gotten out of hand.
>>>
>>
>>
>> the results folder for my VC10 trunk tests is 41.7GB, though that drops
>> to
>> 14.4GB using NTFS compression. The release branch is slightly less.
>>
>> The tests take ages, but can complete over night (on a VM which has only
>> 1
>> cpu core attached).
>
> Thanks for the info.
> --Beman
For a VM, it might make sense not to run the tests in parallel (and/or
restrict the VM to one cpu or core). But in my case, when it's not doing a
nightly build of our own software, my desktops are idle. Hence I need to
make them burn using the bjam -j switch. I have yet to await my first
successful test run, but my guesstimate is that the time will drop from
10-12 hours to 2-3 hours on my quad-core with 8 parallel bjam tasks. Exact
numbers should be coming sometime after the weekend.
--Christoph.