-
-
Notifications
You must be signed in to change notification settings - Fork 18k
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
PERF: fix merging on datetimelike columns to not use object-dtype factorizer #53231
PERF: fix merging on datetimelike columns to not use object-dtype factorizer #53231
Conversation
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) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not fully:
- 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
) - 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 thisneeds_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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense, thanks.
pandas/core/reshape/merge.py
Outdated
@@ -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) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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")
There was a problem hiding this comment.
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
@jbrockmendel anything else here, or good to go? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thanks @jorisvandenbossche |
…ns to not use object-dtype factorizer
… columns to not use object-dtype factorizer) (#53471) * Backport PR #53231: PERF: fix merging on datetimelike columns to not use object-dtype factorizer * Update pandas/core/reshape/merge.py * Check npdtype --------- Co-authored-by: Joris Van den Bossche <jorisvandenbossche@gmail.com> Co-authored-by: Matthew Roeschke <10647082+mroeschke@users.noreply.github.com>
…torizer (pandas-dev#53231) * PERF: fix merging on datetimelike columns to not use object-dtype factorizer * don't try to match resos for Arrow extension array * fix typing * try fix typing * update dtypes check * add whatsnew
…torizer (pandas-dev#53231) * PERF: fix merging on datetimelike columns to not use object-dtype factorizer * don't try to match resos for Arrow extension array * fix typing * try fix typing * update dtypes check * add whatsnew
See #53213 (comment) for context.
Running the added benchmark on current main gives:
versus on this branch:
(and running the standard ns/ns example on pandas 1.5, it also gave around 7ms, so this should restore the performance of 1.5)
doc/source/whatsnew/vX.X.X.rst
file if fixing a bug or adding a new feature.