Re: [jamboost] Boost.Jam tasks for 3.1.5...

From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-02-23 20:38:28

[2003-02-23] Beman Dawes wrote:

>At 04:35 PM 2/23/2003, Rene Rivera wrote:
>
> >Some organizational items... Here's a TODO list for Boost.Jam.
> > ...
> >* Add the timming output Beman wants for the basic build actions.
> >- Difficulty: MEDIUM.
>
>Timing breaks down into two components:
>
>* Build (compile/link) timing.
>* Run timing.
>
>I don't see any way to get "build" timing without support from Boost.Jam. 

Those are the ones I meant in the TODO list.

>But "run" timings can always be reported (to cout) by the program involved, 
>and then extracted by the post-bjam process. I think we missed that point 
>in prior discussions.

No, didn't miss it. I think it was just obvious, and therefore never got
mentioned :-)

>Now I'd certainly like to be able to report build timings, too, but it is a 
>medium or even low priority request.
>
>Would it really be that hard anyhow? Couldn't you just wrap all applicable 
>build commands (c action, c++ action, link action, etc) with a call to a 
>timing program (which starts timer, calls system with the args ([1] being 
>the program to execute), reports timer, returns)?

My guess at difficulty was cursury, and only based on how much bjam code is
likely to get "touched", and have to get tested, by the changes.

But yes, the basic idea would be to add a bjam option: "-d 14", or perhaps
"-i", that would time the actions and print an additional line after the
action is complete full of statisitcal information. Ideally not just
printing the time taken, but memory use, and cpu use would be nice to have
but the timming info is easiest.

There are some caveats involved... like making sure parallel execution
doesn't cause incorrect statistics. And the fact that we can't just call
another program to do the timing as that is not always possible depending on
the platform.

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq