Skip to content

Remove a copy in pcolormesh. #6677

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
Oct 11, 2016

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Jul 3, 2016

This slightly increases the size of the maximum pcolormesh before
hitting a MemoryError. Test with

N = 6000; x, y = mgrid[:N, :N]; z = sin(x + y); pcolormesh(x, y, z)

The patch raises the maximum N to ~8000 on my system (depending on the
load).

OTOH, this probably(?) makes pcolormesh sensitive to later changes in
the input array.

Thoughts?

This slightly increases the size of the maximum pcolormesh before
hitting a MemoryError.  Test with

    N = 6000; x, y = mgrid[:N, :N]; z = sin(x + y); pcolormesh(x, y, z)

The patch raises the maximum N to ~8000 on my system (depending on the
load).

OTOH, this probably(?) makes pcolormesh sensitive to later changes in
the input array.
@tacaswell tacaswell added this to the 2.1 (next point release) milestone Jul 3, 2016
@efiring
Copy link
Member

efiring commented Jul 3, 2016

At least when this is instantiated via pcolormesh, which I suspect is almost always the case, the coordinates array is generated within pcolormesh, so there is no danger--no need to copy it.
Apart from avoiding unnecessary copying, the biggest reduction in memory consumption would come from minimizing the unnecessary use of double precision.

@anntzer
Copy link
Contributor Author

anntzer commented Jul 3, 2016

On coordinates or on the data as well?
Actually perhaps it would makes sense to use float32 internally everywhere given that the extra precision of float64 is unlikely to ever matter?

@efiring
Copy link
Member

efiring commented Jul 3, 2016

Yes, it seems to me that double precision is overkill for coordinates and for data, in almost all plotting situations. The question then is whether it is worth the trouble--and if so, when--to convert to single precision.

@NelleV NelleV changed the title Remove a copy in pcolormesh. [MRG+1] Remove a copy in pcolormesh. Oct 11, 2016
@tacaswell
Copy link
Member

Merging this as it makes things better.

There are still open questions about only using 32 bits (probably should do something like we did in imshow/colormappable to handle float128). Which probably needs means that we need to pull that into cbook.

@tacaswell tacaswell merged commit dc752b3 into matplotlib:master Oct 11, 2016
@QuLogic QuLogic changed the title [MRG+1] Remove a copy in pcolormesh. Remove a copy in pcolormesh. Oct 16, 2016
@anntzer anntzer deleted the copyless-pcolormesh branch February 23, 2017 01:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants