You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first few runs matched the asv results really closely:
In [4]: %timeit func()
781 µs ± 552 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each) # <-- branch
1.27 ms ± 1.82 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each) # <-- master
But running it again just for kicks the results flipped:
In [5]: %timeit func()
1.27 ms ± 5.05 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each) # <-- branch
780 µs ± 4.81 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each) # <-- master
In [5]: %timeit func()
1.26 ms ± 691 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each) # <-- branch
1.26 ms ± 578 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each) # <-- master
In [10]: %timeit func()
1.26 ms ± 818 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each) # <-- branch
773 µs ± 200 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each) # <-- master
Eventually the ~780 number stopped showing up and got replaced a mode between 895-907, but the 1.26-1.27 mode hasn't moved a bit.
No obvious pattern as to which mode will show up in any given run (through they are positively auto-correlated). But in the asv results there must be something causing the modes to be split between the two branches.
I get the same behavior even if I use the same branch, just different terminal windows.
Looking at this with %prun -s cumtime for i in range(1000): func() points at {method 'reduce' of 'numpy.ufunc' objects}
Running some asvs and seeing changes in benchmarks that should be unaffected, yet those changes are consistent across runs.
Hunting this down, I'm replicating the most-weird benchmark (asv reports 1.27±0ms vs 789±3μs) in ipython
The first few runs matched the asv results really closely:
But running it again just for kicks the results flipped:
Eventually the ~780 number stopped showing up and got replaced a mode between 895-907, but the 1.26-1.27 mode hasn't moved a bit.
No obvious pattern as to which mode will show up in any given run (through they are positively auto-correlated). But in the asv results there must be something causing the modes to be split between the two branches.
I get the same behavior even if I use the same branch, just different terminal windows.
Looking at this with
%prun -s cumtime for i in range(1000): func()
points at{method 'reduce' of 'numpy.ufunc' objects}
The total difference is 1.292 - 0.796 = 0.496 and the difference in the
reduce
ufunc is 1.234 - 0.737 = 0.497, which is pretty suggestive.The text was updated successfully, but these errors were encountered: