-
-
Notifications
You must be signed in to change notification settings - Fork 18.3k
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
Conversation
This replaces #50499? |
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 |
Looks good I think |
doc/source/whatsnew/v2.0.0.rst
Outdated
@@ -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``. |
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 sure if mentioning BlockManager here is worth it?
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, I wouldn't mention that (normal users should never pass that)
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.
Thx, removed
I think this is ready as well except the doc comment |
doc/source/whatsnew/v2.0.0.rst
Outdated
@@ -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``. |
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, 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) |
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.
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?
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 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)
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.
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
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.
One more thing here, do you know what is the overhead of this shallow copy? Because our "fastpath" for DataFrame creation goes through here
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.
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.
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.
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?
(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) |
# Conflicts: # doc/source/whatsnew/v2.0.0.rst # pandas/core/reshape/concat.py # pandas/tests/copy_view/test_constructors.py
doc/source/whatsnew/v2.0.0.rst
Outdated
@@ -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 |
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.
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.
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.
Yeah this makes more sense, will change
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 would match this sentence with the bullet point above, since it is basically the same enhancement but for DataFrame instead of Series
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.
Done
@jorisvandenbossche are you ok here? |
Merging, we can still address the mgr case before 2.0 is out if necessary |
…DataFrame/BlockManager creates lazy copy
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. |
doc/source/whatsnew/vX.X.X.rst
file if fixing a bug or adding a new feature.Checking if everything passes