Skip to content
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

API / CoW: constructing DataFrame from DataFrame/BlockManager creates lazy copy #51239

Merged
merged 8 commits into from
Feb 26, 2023

Conversation

phofl
Copy link
Member

@phofl phofl commented Feb 8, 2023

  • closes #xxxx (Replace xxxx with the GitHub issue number)
  • 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.

Checking if everything passes

@phofl phofl marked this pull request as draft February 8, 2023 15:57
@jorisvandenbossche
Copy link
Member

This replaces #50499?

@phofl
Copy link
Member Author

phofl commented Feb 8, 2023

If ci passes everywhere, e.g. I did not miss anything, yes. Wanted to keep the other pr open until a run is through here

@phofl
Copy link
Member Author

phofl commented Feb 8, 2023

Looks good I think

@@ -238,6 +238,9 @@ Copy-on-Write improvements
a modification to the data happens) when constructing a Series from an existing
Series with the default of ``copy=False`` (:issue:`50471`)

- The :class:`DataFrame` constructor now will keep track of references when called
with another :class:`DataFrame` or ``BlockManager``.
Copy link
Member Author

Choose a reason for hiding this comment

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

Not sure if mentioning BlockManager here is worth it?

Copy link
Member

Choose a reason for hiding this comment

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

No, I wouldn't mention that (normal users should never pass that)

Copy link
Member Author

Choose a reason for hiding this comment

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

Thx, removed

@phofl
Copy link
Member Author

phofl commented Feb 9, 2023

I think this is ready as well except the doc comment

@@ -238,6 +238,9 @@ Copy-on-Write improvements
a modification to the data happens) when constructing a Series from an existing
Series with the default of ``copy=False`` (:issue:`50471`)

- The :class:`DataFrame` constructor now will keep track of references when called
with another :class:`DataFrame` or ``BlockManager``.
Copy link
Member

Choose a reason for hiding this comment

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

No, I wouldn't mention that (normal users should never pass that)

@@ -654,6 +654,8 @@ def __init__(
data = data._mgr

if isinstance(data, (BlockManager, ArrayManager)):
if using_copy_on_write():
data = data.copy(deep=False)
Copy link
Member

Choose a reason for hiding this comment

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

The previous PR only did this for DataFrame, not for BlockManager.

We have many places where we have the pattern of new_data = self._mgr.<something>; self._constructor(new_data). In those cases, I think in theory the manager method should already have taken care of the references, and so an additional shallow copy is not needed.

But, it should also be harmless (except for a bit of overheead), since those intermediate manager / blocks will go out of scope?

Copy link
Member Author

Choose a reason for hiding this comment

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

I wanted to do this also for a manager, but this caused all sorts of problems because we kept the Manager alive.

Yeah this is a safety net for something like

new_data = self._mgr

if something:  # False
    ...
return self._constructor(new_data)

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes if they are a true intermediate manager they go out of scope immediately. But if we forgot performing a shallow copy for some reason, this catches this

Copy link
Member

Choose a reason for hiding this comment

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

One more thing here, do you know what is the overhead of this shallow copy? Because our "fastpath" for DataFrame creation goes through here

Copy link
Member

Choose a reason for hiding this comment

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

Small test (not using this branch):

In [97]: df = pd.DataFrame({'a': [1, 2, 3], 'b': [.1, .2, .3]})

In [98]: mgr = df._mgr

In [100]: %timeit mgr.copy(deep=False)
4.1 µs ± 47.4 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)

In [102]: %timeit pd.DataFrame(mgr)
1.47 µs ± 35.7 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

So in relative terms, it's not an insignificant change .. Not fully sure how important this is in real-world cases though.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah it's not totally cheap, it's from 1 to 3 on my machine.

We could keep it out of here if you prefer and investigate other methods of keeping the reference here?

@jorisvandenbossche jorisvandenbossche changed the title ENH: Keep track of references in DataFrame constructor for manager of df API / CoW: constructing DataFrame from DataFrame/BlockManager creates lazy copy Feb 10, 2023
@jorisvandenbossche
Copy link
Member

(I changed the ENH -> API in the title, as for CoW enabled, this is actually a behaviour change (copy=False is the default), not just avoiding a copy where we currently copy)

phofl and others added 2 commits February 10, 2023 17:30
# Conflicts:
#	doc/source/whatsnew/v2.0.0.rst
#	pandas/core/reshape/concat.py
#	pandas/tests/copy_view/test_constructors.py
@@ -243,6 +243,9 @@ Copy-on-Write improvements
a modification to the data happens) when constructing a Series from an existing
Series with the default of ``copy=False`` (:issue:`50471`)

- The :class:`DataFrame` constructor now will keep track of references when called
Copy link
Member

Choose a reason for hiding this comment

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

IIRC, we don't tell users about how CoW is implemented under the hood.

Maybe we can say that the constructor will obey CoW rules when called with a DataFrame.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah this makes more sense, will change

Copy link
Member

Choose a reason for hiding this comment

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

I would match this sentence with the bullet point above, since it is basically the same enhancement but for DataFrame instead of Series

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

@phofl phofl added this to the 2.0 milestone Feb 16, 2023
@phofl
Copy link
Member Author

phofl commented Feb 20, 2023

@jorisvandenbossche are you ok here?

@phofl
Copy link
Member Author

phofl commented Feb 26, 2023

Merging, we can still address the mgr case before 2.0 is out if necessary

@phofl phofl merged commit 9203f9e into pandas-dev:main Feb 26, 2023
@phofl phofl deleted the cons_df branch February 26, 2023 17:43
meeseeksmachine pushed a commit to meeseeksmachine/pandas that referenced this pull request Feb 26, 2023
phofl added a commit that referenced this pull request Feb 26, 2023
… from DataFrame/BlockManager creates lazy copy) (#51650)

Backport PR #51239: API / CoW: constructing DataFrame from DataFrame/BlockManager creates lazy copy

Co-authored-by: Patrick Hoefler <61934744+phofl@users.noreply.github.com>
@jorisvandenbossche
Copy link
Member

Yeah, for the manager case, it might be good to check some benchmarks for this. Although in practice I suppose it will only show up when creating many small DataFrames in some operation, so not sure what a typical use case would be where this would be a significant issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants