pllim/astropy_bisect.md

## astropy_bisect.md

      
    Raw
  

              astropy_bisect.md
            
          
    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.