Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGet rid of coverage.py #32
Merged
Conversation
|
4x executions is pretty awesome. |
|
4x sounds good indeed. which coverage exactly this support now? edge?branch? Does it support for example if we have |
|
Edges and branches, but only at a line granularity, as I wanted other people's opinion on it before investing more time. |
|
Friendly ping: what should I do with this pull-request to get it merged? :P |
|
Hey:) can you rebase please, fix the conflicts and re-run the unit-tests? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
jvoisin commentedJan 13, 2020
Coverage.py does a lot of funky things that we don't
care about, and while its trace function is written in C
and is super-fast-fuck-yeah, since it's using a sqlite
database to store everything, gathering coverage is slow.
A simple'n'stupid pure-python implementation of
edges-coverage yields 4 times more exec/s on my laptop.
This will also allow in the future to use other
kind of metrics to guide the fuzzer, like
the depth of the calltrace for example,
or to have triples instead of pairs for the edges, …