Re: Splitting up perf test compilation and data collection

[Yao Qi <yao at codesourcery dot com>]

On 09/21/2013 01:02 AM, Doug Evans wrote:
> > For example,
> > >We want to be able to run the perf tests in parallel, but we don't want
> > >test data polluted because, for example, several copies of gcc were also
> > >running compiling other tests or other tests were running.
> [pulled out as a separate thread]

Doug,
I don't think running perf tests in parallel is a good idea :).  The
perf data of a test is less useful because of the interference from the 
execution of another test.

> Another thought is to require a convention that perf .exp files are
> written like so:
>
> if [doing_perf_compilation] {
>      ...
> }
>
> if [doing_perf_testing] {
>      ...
> }

AFAICT, this is only useful to the test cases in which compilation takes 
some time, such as gdb.perf/solib.exp.  It is not very common, is it?

I have one test case that doesn't have compilation step, and let GDB to 
load a pre-compiled binary.  The pre-compiled binary is a huge c++ 
program with debug info, and is used to test GDB speed on handling 
symbol and debug info.  It is impossible to compile the huge program in 
each time of running the test case.

--
Yao (éå)