BUG: DataFrame from dict with non-nano Timedelta

[jbrockmendel]

• closes #xxxx
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

xref #44504

This is motivated by a branch (upcoming PR) that makes the Timedelta constructor preserve resolution when passed a np.timedelta64 object. Without this change, test_constructor_dict_timedelta64_index fails because of a dict lookup in lib.fast_multiget.

For non-nano Timedeltas this does significantly hurt performance:

In [1]: import pandas as pd
In [2]: td = pd.Timedelta(days=1, minutes=3)
In [3]: td2 = td._as_unit("ms")

In [4]: %timeit hash(td)
145 ns ± 15.5 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)  # <- main
131 ns ± 3.43 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)  # <- PR

In [5]: %timeit hash(td2)
138 ns ± 16.8 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)  # <- main
1.8 µs ± 42.3 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)  # <- PR

I expect there's room for optimization. Something like:

if self._is_in_pytimedelta_bounds() and not self._has_ns():
    return timedelta.__hash__(self)
else:
    return self._hash_version_in this_pr()

[mroeschke]

Do the unit test hit both the except and else branch?

[jbrockmendel]

just reach one branch, will add test(s)

[mroeschke]

Did these get added?

[jbrockmendel]

good catch, not yet

[jbrockmendel]

updated per request

[github-actions]

This pull request is stale because it has been open for thirty days with no activity. Please update and respond to this comment if you're still interested in working on this.

[mroeschke]

Thanks @jbrockmendel