Brian Hayden found performance issue that was reported at astropy/astropy#10548 .
Will git bisect
identify the offending commit? Reportedly, it was not an issue in 3.2.x but an issue in 4.0.x.
Test script (runme.py
) can be something like this and will be in the root directory of the repository checkout:
import time as _time
import numpy as np
from astropy import table
def main():
time = list(np.random.randint(0, 1000000, 100000))
rate = list(np.random.randint(0, 1000000, 100000))
error = list(np.random.randint(0, 1000000, 100000))
t1 = _time.time()
table.Table([time, rate, error], names=["time", "rate", "error"])
t2 = _time.time()
tt = t2 - t1
if tt > 0.7:
raise ValueError(f'too slow t={tt}s')
if __name__ == '__main__':
main()
- Do a fresh clone of
astropy
repository. - Checkout its
4.0.x
branch. - Find the commit hash that is right after the last 3.2.x release.
git submodule init
git submodule update
git bisect bad
git bisect good 85ae15f5bf09be33eff49d2630ba41df9ef5a840
git bisect run python ./runme.py
Let it run and it will report something like a4ef5f6fdb4c9008b1e6a509bf10f77f2f13cde2 is the first bad commit
.
In this case, the reported bad commit might not be accurate. One needs to adjust runme.py
for a proper test case.
When the culprit in found, git bisect log
can be informational and finally git bisect reset
to end the session.