-
Notifications
You must be signed in to change notification settings - Fork 28
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
Optimize crawling performance #151
Comments
Are you talking about
I think this part can be converted to some execution pool since it does not look to depend on outcomes of any: it simply runs some method and writes output to separate file.
I think making some execution pool with async behavior would be good for this issue. I will try to run before and after this change with cProfile to see whether performance is being affected and tell if it will. |
@MadinaB Just a suggestion: one of the slowest parts of crawler after downloading artifacts and interacting with elements is diffing between two reports. This can be made faster by fixing this: mozilla/grcov#77 since doing this with Rust will be faster, as I think. Another one is parsing 'output.json' to HTML. Now, it is done by parsing coveralls to lcov, and then parsing lcov to html with 'genhtml'. This also may be done faster with solving an issue from grcov: mozilla/grcov#94 |
@MadinaB no, run_in_driver should be fine in terms of performance. I was talking about the way we select the next element to interact with: coverage-crawler/coverage_crawler/crawler.py Line 102 in de41978
Finding all the elements is slow. |
Right now the crawler is quite slow, I think the slowest part is finding all the elements. Perhaps we should apply a greedy approach instead, and just click on the first available element.
The text was updated successfully, but these errors were encountered: