Potential perf regressions introduced by Copy-on-Write

[rhshadrach]

PR #56633 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.

• arithmetic.FrameWithFrameWide.time_op_different_blocks -> PERF: DataFrame(ndarray) constructor ensure to copy to column-major layout #57459
  • op=; shape=(1000000, 10)
  • op=; shape=(1000, 10000)
  • op=; shape=(10000, 1000)
  • op=; shape=(100000, 100)
  • op=; shape=(1000000, 10)
• arithmetic.MixedFrameWithSeriesAxis.time_frame_op_with_series_axis0
  • opname='add'
  • opname='eq'
  • opname='ge'
  • opname='gt'
  • opname='le'
  • opname='lt'
  • opname='mul'
  • opname='ne'
  • opname='sub'
  • opname='truediv'
• arithmetic.NumericInferOps.time_add (no item_cache overhead)
  • dtype=<class 'numpy.int16'>
  • dtype=<class 'numpy.int8'>
  • dtype=<class 'numpy.uint16'>
  • dtype=<class 'numpy.uint8'>
• arithmetic.NumericInferOps.time_multiply (no item_cache overhead)
  • dtype=<class 'numpy.int16'>
  • dtype=<class 'numpy.int8'>
  • dtype=<class 'numpy.uint16'>
  • dtype=<class 'numpy.uint32'>
  • dtype=<class 'numpy.uint8'>
• arithmetic.NumericInferOps.time_subtract (no item_cache overhead)
  • dtype=<class 'numpy.int16'>
  • dtype=<class 'numpy.int8'>
  • dtype=<class 'numpy.uint16'>
  • dtype=<class 'numpy.uint8'>
• eval.Eval.time_add
  • engine='numexpr'; threads='all'
  • engine='numexpr'; threads=1
• eval.Eval.time_mult
  • engine='numexpr'; threads='all'
  • engine='numexpr'; threads=1
• frame_ctor.FromNDArray.time_frame_from_ndarray
• frame_methods.Apply.time_apply_axis_1
• frame_methods.Apply.time_apply_pass_thru
• frame_methods.AsType.time_astype
  • from_to_dtypes=('Float64', 'float64'); copy=True
  • from_to_dtypes=('Int64', 'Float64'); copy=False
  • from_to_dtypes=('Int64', 'Float64'); copy=True
  • from_to_dtypes=('float64', 'Float64'); copy=True
  • from_to_dtypes=('float64', 'float64[pyarrow]'); copy=True
  • from_to_dtypes=('float64[pyarrow]', 'float64'); copy=True
  • from_to_dtypes=('int64[pyarrow]', 'float64[pyarrow]'); copy=True
• frame_methods.Dtypes.time_frame_dtypes
• frame_methods.Fillna.time_fillna
  • inplace=True; dtype='datetime64[ns, tz]'
  • inplace=True; dtype='datetime64[ns]'
  • inplace=True; dtype='timedelta64[ns]'
• frame_methods.Iteration.peakmem_itertuples
• frame_methods.Iteration.peakmem_itertuples_raw
• frame_methods.Iteration.peakmem_itertuples_raw_read_first
• frame_methods.Iteration.peakmem_itertuples_raw_start
• frame_methods.Iteration.peakmem_itertuples_start
• frame_methods.Iteration.time_iteritems_indexing (no item_cache overhead)
• frame_methods.ToDict.time_to_dict_datetimelike (no item_cache overhead)
  • orient='series'
• frame_methods.ToDict.time_to_dict_ints
  • orient='series'
• frame_methods.ToNumpy.time_to_numpy_tall
• frame_methods.ToNumpy.time_to_numpy_wide
• frame_methods.ToNumpy.time_values_tall
• frame_methods.ToNumpy.time_values_wide
• frame_methods.XS.time_frame_xs
  • axis=1
• groupby.Fillna.time_srs_bfill
• groupby.Fillna.time_srs_ffill
• groupby.MultipleCategories.time_groupby_transform
• indexing.Block.time_test
  • param1=True; param2='np.array(True)'
  • param1=True; param2=array(True)
• indexing.DataFrameNumericIndexing.time_loc
  • dtype=<class 'numpy.float64'>; index_structure='nonunique_monotonic_inc'
  • dtype=<class 'numpy.float64'>; index_structure='unique_monotonic_inc'
  • dtype=<class 'numpy.int64'>; index_structure='nonunique_monotonic_inc'
  • dtype=<class 'numpy.int64'>; index_structure='unique_monotonic_inc'
  • dtype=<class 'numpy.uint64'>; index_structure='unique_monotonic_inc'
• indexing.DataFrameStringIndexing.time_at
• indexing.DataFrameStringIndexing.time_getitem_scalar
• indexing.DataFrameStringIndexing.time_loc
• indexing.GetItemSingleColumn.time_frame_getitem_single_column_int
• indexing.GetItemSingleColumn.time_frame_getitem_single_column_label
• indexing.SetitemObjectDtype.time_setitem_object_dtype
• reindex.DropDuplicates.time_frame_drop_dups_bool
  • inplace=False
• reshape.ReshapeExtensionDtype.time_stack
  • dtype='Period[s]'
  • dtype='datetime64[ns, US/Pacific]'
• reshape.ReshapeMaskedArrayDtype.time_stack
  • dtype='Float64'
  • dtype='Int64'
• reshape.Unstack.time_full_product -> CoW: Track references in unstack if there is no copy #57487
  • param1='int'
• reshape.Unstack.time_without_last_row
  • param1='int'
• rolling.EWMMethods.time_ewm
  • constructor='Series'; kwargs_method=({'halflife': 1000}, 'mean'); dtype='float'
  • constructor='Series'; kwargs_method=({'halflife': 1000}, 'mean'); dtype='int'
  • constructor='Series'; kwargs_method=({'halflife': 10}, 'mean'); dtype='float'
  • constructor='Series'; kwargs_method=({'halflife': 10}, 'mean'); dtype='int'
• series_methods.Fillna.time_fillna
  • dtype='string'
• series_methods.ToNumpy.time_to_numpy
• series_methods.ToNumpy.time_to_numpy_float_with_nan
• sparse.ToCooFrame.time_to_coo
• stat_ops.Correlation.time_corr_series
  • method='pearson'
• stat_ops.FrameOps.time_op -> PERF: DataFrame(ndarray) constructor ensure to copy to column-major layout #57459
  • op='kurt'; dtype='Int64'; axis=0
  • op='kurt'; dtype='float'; axis=0
  • op='mean'; dtype='Int64'; axis=None
  • op='mean'; dtype='float'; axis=0
  • op='mean'; dtype='float'; axis=1
  • op='prod'; dtype='float'; axis=0
  • op='prod'; dtype='float'; axis=None
  • op='sem'; dtype='float'; axis=0
  • op='sem'; dtype='float'; axis=None
  • op='skew'; dtype='float'; axis=0
  • op='std'; dtype='Int64'; axis=0
  • op='std'; dtype='Int64'; axis=None
  • op='std'; dtype='float'; axis=0
  • op='std'; dtype='float'; axis=None
  • op='sum'; dtype='Int64'; axis=0
  • op='sum'; dtype='Int64'; axis=None
  • op='sum'; dtype='float'; axis=0
  • op='sum'; dtype='float'; axis=1
  • op='sum'; dtype='float'; axis=None
  • op='var'; dtype='Int64'; axis=0
  • op='var'; dtype='Int64'; axis=None
  • op='var'; dtype='float'; axis=0
  • op='var'; dtype='float'; axis=None
• strings.Construction.time_construction (Series constructor now has copy=True by default)
  • pd_type='series'; dtype='string[python]'

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

[jorisvandenbossche]

Thanks for the list!
I was just planning to look at ASV for CoW today. Investigation of a few of the list:

reshape.Unstack.time_full_product

m = 100
n = 1000

levels = np.arange(m)
index = pd.MultiIndex.from_product([levels] * 2)
columns = np.arange(n)
values = np.arange(m * m * n).reshape(m * m, n)
df = pd.DataFrame(values, index, columns)

%timeit df.unstack()

I am using pandas 2.2.0 to easily be able to switch between then default and CoW mode. With that, I can reproduce a slowdown in unstack. Profiling this with CoW enabled, this seems to be caused by a slower DataFrame construction of the final result in Unstacker.get_result. I assume this is because of the DataFrame constructor now copying an input numpy array, and in this case we can pass copy=False as we know we created the new values ourselves:

pandas/pandas/core/reshape/reshape.py

Lines 242 to 244 in f538741

	return self.constructor(
	values, index=index, columns=columns, dtype=values.dtype
	)

arithmetic.FrameWithFrameWide.time_op_different_blocks op=; shape=(1000000, 10)

n_rows, n_cols = 1_000_000, 10

# construct dataframe with 2 blocks
arr1 = np.random.randn(n_rows, n_cols // 2).astype("f8")
arr2 = np.random.randn(n_rows, n_cols // 2).astype("f4")
df = pd.concat([DataFrame(arr1), DataFrame(arr2)], axis=1, ignore_index=True)
df._consolidate_inplace()

arr1 = np.random.randn(n_rows, max(n_cols // 4, 3)).astype("f8")
arr2 = np.random.randn(n_rows, n_cols // 2).astype("i8")
arr3 = np.random.randn(n_rows, n_cols // 4).astype("f8")
df2 = pd.concat(
    [DataFrame(arr1), DataFrame(arr2), DataFrame(arr3)],
    axis=1,
    ignore_index=True,
)
df2._consolidate_inplace()

%timeit df > df2

This I can also reproduce, and a profile indicates the slowdown comes entirely from the actual > operation on the underlying data. So the one difference seems to be that with CoW, the underlying block values seem to be row major (column major in the transposed Block.values), while without CoW it's the expected column major layout.
Simpler example:

>>> pd.options.mode.copy_on_write = False
>>> arr = np.random.randn(n_rows, n_cols)
>>> df = pd.concat([pd.DataFrame(arr), pd.DataFrame(arr)], axis=1, ignore_index=True)
>>> df._mgr.blocks[0].values.shape
(10, 1000000)
>>> df._mgr.blocks[0].values.flags
  C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : False
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False

>>> pd.options.mode.copy_on_write = True
>>> df = pd.concat([pd.DataFrame(arr), pd.DataFrame(arr)], axis=1, ignore_index=True)
>>> df._mgr.blocks[0].values.flags
  C_CONTIGUOUS : False
  F_CONTIGUOUS : True
  OWNDATA : False
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False

So something seems to go wrong in the DataFrame constructor. With CoW enabled, this should make a copy by default, but when making this copy, it seems to not use the correct C vs F order.

series_methods.ToNumpy.time_to_numpy

N = 1_000_000
ser = pd.Series(np.random.randn(N,))

%timeit ser.to_numpy()

gives

In [80]: %timeit ser.to_numpy()
846 ns ± 57.3 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)   # witout CoW
2.38 µs ± 10.7 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)     # with CoW

In this case there is some extra work being done to return a read-only view:

pandas/pandas/core/base.py

Lines 667 to 669 in f538741

	if using_copy_on_write() and not copy:
	result = result.view()
	result.flags.writeable = False

So it might be this is just that (but haven't checked in detail, from a quick profile nothing stood really out apart from just the body of to_numpy taking a bit longer)

[phofl]

Starting a list here what is a false-positive/expected:

• time_to_dict_datetimelike

both to_dict cases are only as fast because of the item_cache which is something we removed, so nothing we can do

• time_iteritems_indexing

also item_cache, iterating over the columns once is actually twice as fast now, but doing it repeatedly scales linearly now, but this is expected

• groupby.Fillna.time_srs_bfill and fill actually are faster now if you increase the objects, the actual object is tiny, so it's probably the constant cost caused the increase (we are 20% faster if we create an object that runs around 100ms)

• time_loc scales well, it's only on small dfs that we see the slowdown

[jorisvandenbossche]

For the several time_stack ones (eg reshape.ReshapeMaskedArrayDtype.time_stack - dtype='Float64'), it seems that the CoW PR only gave a small perf regression (which I think is again due to the item cache being gone), but those benchmarks show a much bigger slowdown some commits later (I see @rhshadrach and @DeaMariaLeon were discussing those yesterday on slack).
Given that those are not related to CoW, marking them as "done" in the top post here.

[jorisvandenbossche]

For the various arithmetic.NumericInferOps.time_add - dtype=<class 'numpy.int16'> cases (also for time_multiply and time_subtract, I assume): the small slowdown is also due to the item_cache removal.
And the fact that we only see it for the lower bitwidth dtypes, is because it seems the actual addition operation for those is much faster, and so the overhead of getting the column becomes relatively bigger, making this noticeable in the benchmark.
Marked those as "done".

[jorisvandenbossche]

For strings.Construction.time_construction, the reason of the slowdown is that Series(nparr) now by default makes a copy, so that is expected (without the benchmark using copy=False)

[jorisvandenbossche]

stat_ops.FrameOps.time_op

dtype = "float"
axis = 0
values = np.random.randn(100000, 4)
df = pd.DataFrame(values).astype(dtype)

%timeit df.sum(axis=axis)

This was also because of the constructor copying the array but not creating the correct columnar layout, and so this should be fixed on main with #57459 (confirmed locally, in a few days we should also see this on the ASV results)

[jorisvandenbossche]

series_methods.Fillna.time_fillna - dtype='string'

dtype = "string"
N = 10**6
data = np.array([str(i) * 5 for i in range(N)], dtype=object)
na_value = pd.NA
fill_value = data[0]
ser = pd.Series(data, dtype=dtype)
ser[::2] = na_value

%timeit ser.fillna(fill_value)

This is a slowdown that I can reproduce, and is due to the additional hasna check that we added (linking to the 2.2 code, so its clearer what is run in case of CoW vs before):

pandas/pandas/core/internals/blocks.py

Lines 2321 to 2329 in 3cc5afa

	if using_cow and self._can_hold_na and not self.values._hasna:
	refs = self.refs
	new_values = self.values
	else:
	copy, refs = self._get_refs_and_copy(using_cow, inplace)
	try:
	new_values = self.values.fillna(
	value=value, method=None, limit=limit, copy=copy

So for CoW, we added the additional check to see if there are actually NAs to fill, and if not just return the original values + the correct refs.
But for the case where we are actually filling NAs, it seems this _hasna check gives a significant overhead (around 30% in this example, and at least for string dtype, since that's the only dtype that shows a regression in the ASV results)

Now, that is also only for our own object-dtype string dtype, so given we have pyarrow-backed strings as a faster alternative if you care about performance, this is probably an OK trade-off (since the hasna check gives other benefits, like avoiding a copy if no NAs)

[jorisvandenbossche]

Although after taking a quick look at isna for strings, it's also easy to speed it up, to offset the additional overhead a bit -> #57733

[rhshadrach]

I've looked through the most recent benchmarks, confirmed #57431 (comment), and checked off the box.