REF: remove fast_apply

[jbrockmendel]

xref #32083, one more coming that i think finishes off libreduction

[WillAyd]

Any perf differences here?

[mroeschke]

Progress on #31845 hits this code path you are removing. Happy to remove - would just like to see this PR move forward sooner rather than later.

[jbrockmendel]

Any perf differences here?

Ran full asv run overnight and am shocked to see no differences. Do we just not have asvs that hit this?

[jreback]

it’s possible we only have test that hit this - maybe have to construct one?

[jbrockmendel]

Tentatively looks like I ran the asvs on the wrong pair of commits, re-running now.

[jbrockmendel]

OK, a run with just -b groupby gives:

       before           after         ratio
     <master>         <no-fast-apply>
+     5.73±0.05ms          277±4ms    48.30  groupby.Apply.time_scalar_function_single_col
+      19.0±0.1ms          690±5ms    36.37  groupby.Apply.time_scalar_function_multi_col
-      13.2±0.1ms       11.7±0.4ms     0.89  groupby.Nth.time_series_nth('float64')
-         754±2μs          667±3μs     0.88  groupby.GroupByMethods.time_dtype_as_group('object', 'unique', 'direct')
-         755±3μs          666±1μs     0.88  groupby.GroupByMethods.time_dtype_as_group('object', 'unique', 'transformation')
-         813±5ms         702±20ms     0.86  groupby.Apply.time_copy_overhead_single_col
-      2.05±0.06s       1.75±0.02s     0.85  groupby.Apply.time_copy_function_multi_col

so that's pretty rough

[mroeschke]

Ouch. Guessing ripping it out is not justifiable given the performance hit.

[jbrockmendel]

Ouch. Guessing ripping it out is not justifiable given the performance hit.

Yah. On the plus side, profiling it has turned up some optimization opportunities, locally ive got the worst one down from 48x to 10x.

[jbrockmendel]

closing to clear the queue, will revisit after 1.0.2