Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce the time it takes to run the tests #396

Closed
muep opened this issue Sep 6, 2015 · 10 comments
Closed

Reduce the time it takes to run the tests #396

muep opened this issue Sep 6, 2015 · 10 comments
Assignees
Labels
Milestone

Comments

@muep
Copy link

muep commented Sep 6, 2015

Some tests in the glm test suite seem to be a bit wasteful in their use of CPU time.

For example, gtx_fast_trigonometry.cpp seems to go through the trouble of testing functions with every possible float value between -glm::pi() and glm::pi(). On my midrange-ish desktop, running that test in release mode takes more than 3 minutes.

I am fairly sure that testing e.g. just one percent of those possible values would give a quite accurate view on how fast those functions are.

Fortunately, most of the tests in the test suite produce useful results in a fraction of a second here. Making the CPU intensive ones run e.g. within ten seconds on usual hardware would make it way less cumbersome to run the whole suite.

@Groovounet
Copy link
Member

Hi,

Why do you need to run the tests?

Thanks,
Christophe

@JesseTG
Copy link

JesseTG commented Sep 6, 2015

Why not?

Also, somebody might be contributing functionality; wouldn't want any changes to break a test, now, would we?

@muep
Copy link
Author

muep commented Sep 6, 2015

I would want to verify that GLM versions shipped in Fedora at least pass their test suite on all supported architectures, on both clang and gcc and with at least minimal build flags and -std=c++11 and -std=c++14 . It takes a long time to do this verification if a single test run on a midrange computer takes over 6 minutes.

Especially for ARM machines, having highly CPU intensive tests is inconvenient. The 6 minutes could easily become something like 60 minutes.

I would not mind that much if the CPU time was used for something that is clearly necessary and useful. But I am currently not convinced that testing all of the possible float values is an useful thing to test routinely.

@Groovounet Groovounet added the bug label Sep 6, 2015
@Groovounet Groovounet added this to the GLM 0.9.7 milestone Sep 6, 2015
@Groovounet Groovounet self-assigned this Sep 6, 2015
@Groovounet
Copy link
Member

This bug is resolved in master branch for GLM 0.9.7.1 release.

Thanks for reporting,
Christophe

@muep
Copy link
Author

muep commented Sep 6, 2015

Thank you for addressing this so quickly.

@Groovounet
Copy link
Member

That test was orders of magnitude slower than any other test so yes that's a bug. And actually left over for when I was studying better fast trig.

@muep
Copy link
Author

muep commented Sep 6, 2015

Would you be willing to accept patches that'd reduce the time it takes to run other, less CPU time intensive tests that still tend to take e.g. over 5 seconds on my midrange desktop?

Provided of course that they do not seem to significantly increase the likelihood of bugs getting through.

@Groovounet
Copy link
Member

Sure. The problem is that I have been adding performance tests for GLM but there is no CMake toggle to enable them. I think this is what it's needed typically.

There are probably proper unit tests that could be faster but typically they are really fast.

This said, I had a look at the performance tests and basically disabled them as it's still work in progress. This led from total exec time dropping from more than a minute and half to 16 seconds.

@elect86
Copy link

elect86 commented Jan 31, 2018

Sorry for the dummy question, but how can I run the tests from within Visual Studio?

I keep getting `unable to start the program, access is denied"..

@Groovounet
Copy link
Member

You need to set RUN_TESTS as "Start up" project. (right click on RUN_TESTS in Solution Explorer)
Then build.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants