What a coincidence - I was just about to send out a very similar email.
I was looking in to setting up a valgrind build of VXL, and the
mentioned tests listed below would make that impractical.
If it really isn't possible to speed up those tests withou loosing their
value, then I would suggest guarding them behind a RUN_SLOW_TESTS
variable in CMake. Those dashboard builds that need a lot of time for
their tests (no optimiser, valgrind, etc.) can disable RUN_SLOW_TESTS.
We use this pattern extensively in our private repository and it appears
to work well.
Often we have faster cursory versions of slow tests which run when
RUN_SLOW_TESTS is disabled.
A general rule I try to enforce on our repository is that 90% of tests
should run in less than 5 seconds without compiler optimisation. Any
test that takes longer than 30 seconds without optimisation should be
marked as a slow test.
Wheeler, Frederick W (GE, Research) wrote:
> In monitoring a test build for the new VXL release, and then by
> checking the dashboard, I notice that some tests take a very long
> time to run. bvxm_test_voxel_world_update and
> bvxm_test_voxel_world_mog_imag combined seem to be taking like 20
> minutes on my computer. As I write this,
> bvxm_test_voxel_world_mog_imag just finally timed out. Is there is an
> easy way to trim these tests back, while still getting the code
> If you sort the tests on a page like this by Time you can see that
> there are a few tests that take much longer than the others.
> Here are the top ten, with times in seconds:
> bvxm_test_gen_synthetic_world Passed 355.00
> bvxm_test_voxel_world_update Passed 332.00
> mmn_test_diffusion_solver Passed 166.00
> bvxm_test_bvxm_normalize_image_process Passed 159.00
> bvxm_test_voxel_world_mog_image Passed 149.00
> mmn_test_lbp_solver Passed 91.00
> pseudo_match_2d_test Passed 65.00
> brec_test_brec_create_mog_image_process Passed 53.00
> brec_test_brec_update_changes_process Passed 44.00
> bvxm_test_rpc_registration_process Passed 44.00
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> Vxl-maintainers mailing list