* Run 2to3 on tools directory
* Delete github_stats_tracking
* Re-run 2to3
* Remove unused script
* Remove unused script
* Remove unused line count utility
* Yapf. Isort
* Remove accidentally included file
* Migrate tools/distrib directory to python 3
* Remove unnecessary shebang
* Restore line_count directory
* Immediately convert subprocess.check_output output to string
* Take care of Python 2 shebangs
* Invoke scripts using a Python 3 interpreter
* Yapf. Isort
* Try installing Python 3 first
* See if we have any Python 3 versions installed
* Add Python 3.7 to Windows path
* Try adding a symlink
* Try to symlink differently
* Install six for Python 3
* Run run_interop_tests with python 3
* Try installing six in python3.7 explicitly
* Revert "Try installing six in python3.7 explicitly"
This reverts commit 2cf60d72f3.
* And debug some more
* Fix issue with jobset.py
* Add debug for CI failure
* Revert microbenchmark changes
This fixes a crash in the grpc_performance_profile_* and grpc_e2e_performance_* tests.
Example failure: https://source.cloud.google.com/results/invocations/2112f2d5-db91-4901-87cb-cc9865f351f1/targets
The daily performance test passes with this fixit branch:
http://sponge2/23d4df20-f4dd-48ee-8789-4cd96b078ed5.
Additional fixes:
reorder imports according to the google style guide
replace deprecated cgi.escape library method with html.escape
In case it comes up, with respect to upgrading from py2 to py3, the iter{items,keys,values} methods are intentionally replaced with the less-efficient-in-python2 non-iter versions. This is a recommended practice even when supporting both python versions, and this is not performance-critical code.
Additional note: there is no performance difference btw py2 and py3 (~80 minutes to finish)
... one that runs hourly and uploads to bigquery (for regression
detection)
... and one that will run daily and not upload to bigquery (for
flamegraph generation)
- More robustly run processes in the background
- Detect and use pypy if available
- Add a --latency_profile flag to control whether to run the latency profiling stuff
Current latency profiles have their tails dominated by writing latency
logs, which is hugely undesirable.
Now when a thread log fills up, push it to a background thread to write
to disk. At shutdown, wait for all latency traces to be flushed.