Skip to content

PERF: fix merging on datetimelike columns to not use object-dtype factorizer #53231

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
May 31, 2023
32 changes: 32 additions & 0 deletions asv_bench/benchmarks/join_merge.py
Original file line number Diff line number Diff line change
Expand Up @@ -324,6 +324,38 @@ def time_i8merge(self, how):
merge(self.left, self.right, how=how)


class MergeDatetime:
params = [
[
("ns", "ns"),
("ms", "ms"),
("ns", "ms"),
],
[None, "Europe/Brussels"],
]
param_names = ["units", "tz"]

def setup(self, units, tz):
unit_left, unit_right = units
N = 10_000
keys = Series(date_range("2012-01-01", freq="T", periods=N, tz=tz))
self.left = DataFrame(
{
"key": keys.sample(N * 10, replace=True).dt.as_unit(unit_left),
"value1": np.random.randn(N * 10),
}
)
self.right = DataFrame(
{
"key": keys[:8000].dt.as_unit(unit_right),
"value2": np.random.randn(8000),
}
)

def time_merge(self, units, tz):
merge(self.left, self.right)


class MergeCategoricals:
def setup(self):
self.left_object = DataFrame(
Expand Down
6 changes: 6 additions & 0 deletions pandas/core/arrays/datetimes.py
Original file line number Diff line number Diff line change
Expand Up @@ -728,6 +728,12 @@ def _has_same_tz(self, other) -> bool:
other_tz = other.tzinfo
return timezones.tz_compare(self.tzinfo, other_tz)

def _is_tzawareness_compat(self, other: DatetimeArray) -> bool:
"""
Return True if either both self and other are tz-aware or both are tz-naive.
"""
return not ((self.tz is None) ^ (other.tz is None))

def _assert_tzawareness_compat(self, other) -> None:
# adapted from _Timestamp._assert_tzawareness_compat
other_tz = getattr(other, "tzinfo", None)
Expand Down
19 changes: 14 additions & 5 deletions pandas/core/reshape/merge.py
Original file line number Diff line number Diff line change
Expand Up @@ -88,6 +88,7 @@
from pandas.core.arrays import (
ArrowExtensionArray,
BaseMaskedArray,
DatetimeArray,
ExtensionArray,
)
from pandas.core.arrays._mixins import NDArrayBackedExtensionArray
Expand All @@ -103,7 +104,6 @@
if TYPE_CHECKING:
from pandas import DataFrame
from pandas.core import groupby
from pandas.core.arrays import DatetimeArray

_factorizers = {
np.int64: libhashtable.Int64Factorizer,
Expand Down Expand Up @@ -2355,12 +2355,14 @@ def _factorize_keys(
rk = extract_array(rk, extract_numpy=True, extract_range=True)
# TODO: if either is a RangeIndex, we can likely factorize more efficiently?

if isinstance(lk.dtype, DatetimeTZDtype) and isinstance(rk.dtype, DatetimeTZDtype):
if (isinstance(lk, DatetimeArray) and isinstance(rk, DatetimeArray)) and (
lk._is_tzawareness_compat(rk)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is checking this way more performant?

Copy link
Member Author

@jorisvandenbossche jorisvandenbossche May 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No idea, but that was also not the reason for using this: what we want to check here is that we have either two DatetimeTZDtypes, or two np.dtype("M8").

So initially I expanded the original if isinstance(lk.dtype, DatetimeTZDtype) and isinstance(rk.dtype, DatetimeTZDtype) with something like or (isinstance(lk.dtype, np.dtype) and lk.dtype.kind == "M" and isinstance(rk.dtype, np.dtype) and rk.dtype.kind == "M"). But this got a bit long, and so this seemed simpler (and since we are calling a specific DatetimeArray method in the if-block, it also make sense code-logic-wise to check for it).

(the performance benefit of the PR comes from avoiding using the ObjectFactorizer)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. I prefer the status quo here largely bc it avoids introducing a new method. Not a huge deal though.

BTW new optimized check for isinstance(lk.dtype, np.dtype) and lk.dtype.kind == "M" is lib.is_np_dtype(lk.dtype, "M")

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, with is_np_dtype that can be shorter, so reverted back to the original dtype checks (and now with the added dtype check for numpy dtypes), avoiding the new method

):
# Extract the ndarray (UTC-localized) values
# Note: we dont need the dtypes to match, as these can still be compared
lk, rk = cast("DatetimeArray", lk)._ensure_matching_resos(rk)
lk = cast("DatetimeArray", lk)._ndarray
rk = cast("DatetimeArray", rk)._ndarray
lk, rk = lk._ensure_matching_resos(rk)
lk = cast(DatetimeArray, lk)._ndarray
rk = cast(DatetimeArray, rk)._ndarray

elif (
isinstance(lk.dtype, CategoricalDtype)
Expand Down Expand Up @@ -2388,6 +2390,13 @@ def _factorize_keys(
# "_values_for_factorize"
rk, _ = rk._values_for_factorize() # type: ignore[union-attr]

if needs_i8_conversion(lk.dtype) and lk.dtype == rk.dtype:
# GH#23917 TODO: Needs tests for non-matching dtypes
# GH#23917 TODO: needs tests for case where lk is integer-dtype
# and rk is datetime-dtype
lk = np.asarray(lk, dtype=np.int64)
rk = np.asarray(rk, dtype=np.int64)
Comment on lines +2396 to +2401
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part was (accidentally?) removed in #49876. So there won't be any tests failing from leaving this out (because falling back to the object factorizer also gives correct results), but it is necessary to ensure we use the faster factorizer for datetimelikes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i expect that the relevant cases should go through the elif isinstance(lk, ExtensionArray) and lk.dtype == rk.dtype: branch above?

Copy link
Member Author

@jorisvandenbossche jorisvandenbossche May 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not fully:

  1. It did go through there before but only for tz-naive data (and same unit), now we already convert to a numpy array in the if isinstance(lk.dtype, DatetimeTZDtype) ... block by getting the _ndarray of lk and rk (but we could not do that there, and let it go through the block that calls _values_for_factorize)
  2. even when going through this block, the DatetimeArray._values_for_factorize returns the _ndarray, which is the M8 numpy array, not an integer numpy array. So we still need this needs_i8_conversion.
    Now, we should maybe change _values_for_factorize? (but that's probably more for something targetting 2.1, and didn't check the other places where _values_for_factorize is being used)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense, thanks.


klass, lk, rk = _convert_arrays_and_get_rizer_klass(lk, rk)

rizer = klass(max(len(lk), len(rk)))
Expand Down