Skip to content

REF: de-duplicate nested-dict handling in DataFrame construction #41785

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 1 commit into from
Jun 2, 2021

Conversation

jbrockmendel
Copy link
Member

  • closes #xxxx
  • tests added / passed
  • Ensure all linting tests pass, see here for how to run them
  • whatsnew entry

This was the motivation for #41707. This will introduce some overhead, but will also prevent the behaviors from getting out of sync again.

@jreback jreback added Clean Refactor Internal refactoring of code labels Jun 2, 2021
@jreback jreback added this to the 1.3 milestone Jun 2, 2021
@jreback
Copy link
Contributor

jreback commented Jun 2, 2021

oh i like this!

@jreback jreback merged commit a8b313f into pandas-dev:master Jun 2, 2021
@jbrockmendel jbrockmendel deleted the ref-homogenize-3 branch June 2, 2021 19:30
@jorisvandenbossche
Copy link
Member

This might have caused a big slowdown in one of the benchmarks: https://pandas.pydata.org/speed/pandas/#frame_ctor.FromDicts.time_nested_dict_int64?python=3.8&Cython=0.29.21

@jbrockmendel can you verify this?

@jbrockmendel
Copy link
Member Author

That looks plausible; noted in the OP we'd take a perf hit in these cases

@jorisvandenbossche
Copy link
Member

Yes, but "some overhead" turns out to be a 6x slowdown.
So then having the cython implementation (and the added effort of ensuring it is kept in sync) might be worth it.

@jbrockmendel
Copy link
Member Author

do you have anything in particular in mind? could revert until after the release

@jorisvandenbossche
Copy link
Member

I didn't follow the original context, but IIUC, this PR didn't "fix" anything, correct? (like a bug) But it did remove a faster cython implementation to reduce maintenance cost in the idea the added overhead would only be small?

If that's the case, and the overhead actually turns out to be not so small (6x according to the benchmark), then it's a tradeoff we need to make: do we find the speed worth it to maintain the cython implementation.
If we say yes to that, then yes I suppose this means to revert the PR; but it would not be only until after the release (not sure what the point of that would be).

@jbrockmendel
Copy link
Member Author

I didn't follow the original context, but IIUC, this PR didn't "fix" anything, correct? (like a bug) But it did remove a faster cython implementation to reduce maintenance cost in the idea the added overhead would only be small?

This context is that this follows #41707, which did fix a bug in the Series constructor that didn't affect DataFrame construction because they had separate implementations.

@jorisvandenbossche
Copy link
Member

I opened #42248 to keep track of this regression.

jbrockmendel added a commit to jbrockmendel/pandas that referenced this pull request Jul 1, 2021
jreback pushed a commit that referenced this pull request Jul 8, 2021
meeseeksmachine pushed a commit to meeseeksmachine/pandas that referenced this pull request Jul 8, 2021
simonjayhawkins pushed a commit that referenced this pull request Jul 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Clean Refactor Internal refactoring of code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants