Slower speed of saving plotted Geographic data with cartopy
See original GitHub issueDescription
I’m plotting large datasets using proplot (0.9.5.post78) and cartopy (0.20.0). The speed is much slower than the pyplot one.
Steps to reproduce
import time
import numpy as np
import proplot as pplt
import cartopy.crs as ccrs
import matplotlib.pyplot as plt
import warnings
warnings.filterwarnings('ignore')
offset = -40
lon = np.linspace(offset, 360 + offset - 1, 3000)
lat = np.linspace(-60, 60 + 1, 500)
state = np.random.RandomState(51423)
data = state.rand(len(lat), len(lon))
def proplot_test():
start = time.time()
fig, axs = pplt.subplots(proj='stere', figsize=(4,4))
axs.coastlines()
axs.pcolormesh(lon, lat, data, cmap='viridis')
end = time.time()
print('proplot plot cost: ', end - start)
fig.savefig('test_proplot.jpg', dpi=300)
save_end = time.time()
print('proplot save cost: ', save_end - end)
def pyplot_test():
start = time.time()
fig, ax = plt.subplots(figsize=(4,4), subplot_kw=dict(projection=ccrs.Stereographic()))
ax.coastlines()
ax.pcolormesh(lon, lat, data, cmap='viridis', transform=ccrs.PlateCarree())
end = time.time()
print('pyplot plot cost: ', end - start)
fig.savefig('test_pyplot.jpg', dpi=300)
save_end = time.time()
print('pyplot save cost: ', save_end - end)
proplot_test()
pyplot_test()
Expected behavior: [What you expected to happen]
The speed is similar with pyplot.
Actual behavior: [What actually happened]
proplot plot cost: 2.1709158420562744
proplot save cost: 5.2430949211120605
pyplot plot cost: 1.9175093173980713
pyplot save cost: 1.4209530353546143
In jupyterlab, the cost of plotting data by proplot is 7s while the pyplot one is 3.7s. I suppose this is the same problem of saving figures, because jupyter notebook needs to show the figure inline.
Issue Analytics
- State:
- Created 2 years ago
- Comments:17
Top Results From Across the Web
Hi-res plots can be quite slow · Issue #4 · proplot-dev ... - GitHub
When I use hydrogen inside the atom editor it works like a charm (fast). ... Slower speed of saving plotted Geographic data with...
Read more >Using cartopy with matplotlib - SciTools
Beautifully simple maps#. Cartopy has exposed an interface to enable easy map creation using matplotlib. Creating a basic map is as simple as...
Read more >Cartopy/Matplotlib savefig slow for lcc projections
I ran a quick check using the the code snippet below and found that it takes about 10x as long to save using...
Read more >Increase map size with subplots and Cartopy
I can't execute your code due to lack of data so here's a general ... only option is to increase the plot-extent or...
Read more >Plotting - Xarray
Dataset specific plotting routines are also available (see Datasets). Here we focus mostly on arrays 2d or larger. If your data fits nicely...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Ok cool. Yep in your first example cartopy wasn’t having to transform anything at all (because the default is native map coordinates rather than longitude-latitude), so it was faster. Keep in mind proplot’s only dependency is
matplotlib
(no specific version) so yourproj
version differences aren’t due to proplot – something else is going on.I also figured out that the speedup shown above is only relevant for cartopy plots. This fix seems obvious because it is obvious – matplotlib’s
Axes.get_tightbbox()
already skips artists that are bounded by the subplot edge, however its method for skipping them (for some reason) fails with cartopy artists, while my method (for some reason) succeeds. May submit a cartopy PR at some point. Relevant lines:https://github.com/matplotlib/matplotlib/blob/9765379ce6e7343070e815afc0988874041b98e2/lib/matplotlib/axes/_base.py#L4646-L4657
Great! Not so much a “bug” just a limitation of how “tight layout” is calculated – in order to get the positions of every object in the subplot (and, thus, ensure the subplots are sufficiently separated to prevent overlapping content), we have to draw every object in the subplot. Then, in order to save or display the figure, we have to draw the objects again using the relevant backend. However, it could probably be massively improved by skipping objects that are “clipped” by the subplot edges (i.e., skipping objects with
obj.get_clip_on()
set toTrue
). I’ll experiment with this for the next version.