Re: [boost] [testing] Refactoring serialization tests, and possibly others.

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-10-13 01:12:59

troy d. straszheim wrote:
> On Wed, Oct 12, 2005 at 10:14:34AM -0500, Rene Rivera wrote:
>>To add to what Dave said... We've been personally bitten by assuming 
>>that bjam is slow in certain places. Only to humiliate ourselves after 
>>looking at the profile data :-)
> 
> Sorry, I had no idea the phrase "bjam calculating dependencies" was a
> touchy subject.  Please replace with "build system doing whatever it
> does before the first compilation starts, as timed by looking at my
> watch".

In that case... Yea it's slow ;-) We know. It's slightly better now. It 
will continue to get better.

> When you then consider how much duplicated work
> there is for the compiler and linker, after all the templates in those
> 49,800 lines are instanatiated...  there's your speedup. 

Yes, I can imagine. I've also seen the opposite happen. Including more 
code makes it exponentially slower because it ends up eating much more 
memory and memory starts trashing.

> But one can
> just use the test_many.cpp which #includes all the other .cpps.
> Whatever you guys are comfortable with.  

I thinks that's the only option you have now.

> <lib>../../test/build/boost_prog_exec_monitor is fed directly to rule
> "run" inside rule run-template, which is invoked from run-(w)invoke,
> which is called sometimes from test-bsl-run_files, sometimes from
> test-bsl-run.  But after this change, some files currently fed to
> test-bsl-run (namely those containing the string "demo") will need the
> exec_monitor, and some (all the others) will need the
> unit_test_framework.  I could copy/past the whole group of rules and
> make some of them run-template-exec-monitor and some
> run-template-unit-test-framework, but that seemed ugly.  Hopefully
> I've been clear, I have a lot of balls in the air.

Yes, I get it now. Perhaps the easiest way is to not set all that all 
the way down in the run-template rule. But instead pass it in from 
above. And to do that you can employ "template" targets, to reduce the 
typing. To see how "template" targets help in regression tests take a 
look at the libs/spirit/test/Jamfile which uses a variety of templates 
to pass down such configuration setup down to it's own custom run rule 
int he same vein that serialization has.

> Here's that profiling info:

Basic comment... Yea since you reduced the total number of build targets 
by some factor, the build startup will be mostly directly reduced by 
that same factor.

In the CVS version of bjam there are some basic improvements for 
operations that deal with the file system like:

0	0	16	GLOB
6	6	96	GLOB
54	54	161	PWD
453	453	1329	PWD

In particular PWD now takes on average "0" time.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org