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

Log the runtime #430

Open
janmotl opened this issue May 5, 2019 · 4 comments
Open

Log the runtime #430

janmotl opened this issue May 5, 2019 · 4 comments
Labels
good first issue Start here if you want to lend a hand

Comments

@janmotl
Copy link

janmotl commented May 5, 2019

Currently, the log in the database does not contain any information about the runtime of the individual job_ids. But I think this could be quite an interesting information to have.

The runtime can be logged either as a duration or with two timestamps: start_job and end_job.

@abingham
Copy link
Contributor

abingham commented May 9, 2019

I'm not completely opposed to adding this, but I do worry about adding features that don't serve any real purpose. I don't see any immediate benefit to CR of adding this information to the output.

But I'm happy to be convinced. What do you plan to use this information for? How do you see it improving Cosmic Ray?

@janmotl
Copy link
Author

janmotl commented May 9, 2019

Permutation testing is slow. And it is generally not enough to run it just once. Hence, I wanted to:

  1. narrow the scope of what is permutation tested in my code base
  2. reduce the set of applicable permutation operators
  3. see the estimate of how much time it will take, if I do the tasks above

It felt natural to look for the answer to the 3rd point it in the log.

Furthermore, if you want to improve something, you generally have to first be able to measure it. Hence, I thought that it could be useful to have runtime measures for further development of Cosmic Ray.

@abingham
Copy link
Contributor

Sorry for the delayed response; I've had to spend some time sorting out CR problems on windows...not my favorite thing to do.

My general approach to estimating testing time has been to simply multiply the runtime of my test suite on unmutated code by the number of mutations. This obviously isn't perfect, but it gives you a good idea.

I won't be able to put any time real towards capturing/storing run times any time soon, but if you want to put some effort into it I'd be happy to help you. Off the top of my head, you'd need to:

  • update the database format to store the timing information
  • put a timer around the test runs
  • communicate the timing information from testing subprocesses to the cosmic-ray exec process.
  • Update any relevant reporting tools (e.g. cr-html).

@janmotl
Copy link
Author

janmotl commented May 17, 2019

I have projects to work on. If someone else would like to write the PR, go ahead.

@abingham abingham added the good first issue Start here if you want to lend a hand label May 28, 2019
@abingham abingham reopened this May 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Start here if you want to lend a hand
Projects
None yet
Development

No branches or pull requests

2 participants