[RFC] testsuite/performance

[Jerry Quinn <jlquinn at optonline dot net>]

Benjamin Kosnik writes:
 > Hello people. 
 > 
 > There's long been talk of storing performance-related tests in the
 > testsuite itself. Here's a first crack at actually doing this. In
 > preparing this patch, I did a lot of CVS/web/mailing list excavation
 > (including the finding of Loren's post to switch back to the pool
 > allocator on 2001-05-03, which it seems is the basis for the subsequent
 > allocator tests). It was pretty interesting, but perhaps I forgot
 > somethings. If so, let me know.
 > 
 > I thought it was a good idea to put these sources in the testsuite, even
 > if they are not run by default, so that the maintainers are not all
 > carting around little test programs in a separate directory. (As I've
 > been doing for much too long now.) Thoughts? Suggestions and improvements?

Having this is a great idea.  Being able to run the individual tests
easily to get timing outputs with different flags is probably
important, whether manually or through the makefiles.

If we're going have build support, being able to profile easily would
be very useful.  This involves building the library with profiling,
building the testcase with profiling, and running gprof or oprofile.
Profiling would be handy as I almost invariable forget to build with
-fprofile-arcs the first time in addition to -pg :-)

Profiling would definitely not want to run all test cases at the same
time.

I don't think I would run any of these by default, since they are only
useful if you have a benchmark timing to compare them to.

Jerry Quinn