Potential regression induced by PR #57328

[rhshadrach]

PR #57328 may have induced a performance regression. If it was a necessary behavior change, this may have been expected and everything is okay.

Please check the links below. If any ASVs are parameterized, the combinations of parameters that a regression has been detected for appear as subbullets.

• frame_methods.Fillna.time_fillna
  • inplace=True; dtype='object'

Subsequent benchmarks may have skipped some commits. The link below lists the commits that are between the two benchmark runs where the regression was identified.

Commit Range

cc @phofl

[phofl]

I’ll dig deeper later, but pretty sure that this is expected.

[phofl]

I can't reproduce this locally, this might be related to how we run benchmarks maybe?

Locally, the example actually got faster, which is kind of what I would expect based on the fact that downcasting isn't cheap

[rhshadrach]

I think this is due to the use of inplace within ASV. When we downcasted, future calls would be faster. If I add a copy:

df.copy(deep=True).ffill(inplace=inplace)

Then I get

195 ms ± 3.72 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)    <-- prior to #57328 
146 ms ± 2.02 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)  <-- main