-
Notifications
You must be signed in to change notification settings - Fork 162
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
Extracting runtimes from TestDirectory logs #305
Comments
There is no good reason for this change, I'll fix it. |
It would be sensible for TestDirectory to offer an API for accessing the performance information from a run. Also, if possible, a list of files which failed testing. |
@ChrisJefferson Yes, please - while we may think of an API later, restoring the old output would help immediately. Since |
Output on master now looks like this:
So it should be again possible to extract the individual file runtimes from this. Of course we also change TestDirectory to somehow return a list with an entry for each |
@alex-konovalov what's the status of this? |
@alex-konovalov What's the status of this? If this is broken, can you please point out where the (currently broken) code for extracting the timings is (which repository, file, which function name etc.) so that somebody who'd be willing to help with this could contribute? |
It is https://github.com/gap-system/gap-distribution/blob/master/testing/plots.sh but quite tied to Jenkins setup, so I am not sure that it will be useful to somebody. |
We are not using the Jenkins setup anymore |
I've discovered that this functionality is broken for a while in the master branch. In the stable branch, the log has
so I can extract the runtime with
where GTEST is in
arithlst hash2 primsan xgap grppcnrm grpmat grpperm matrix grplatt bugfix grpprmcs grpconst
to build plots in Jenkins to track the performance of selected tests.Now in the master branch the log looks like
Since there is no name of the test file in the same line with the runtime, it's no longer possible to extract the runtime in the same way (also, I do not understand what's the meaning of the third number which appears in that line).
One approach would be to fix this by adding the filename to the line in question. Another could consider going further and providing a way to save, accumulate and compare such data, triggering an alert in case of significant performance regressions. There were some ideas about that in the past.
The text was updated successfully, but these errors were encountered: