Just importing matplotlib.figure (which is necessary if you want to do anything with matplotlib, I'm not even talking about pyplot) already imports these extension modules, so it's not clear what actual use cases would get accelerated?

$ MPLCONFIGDIR=/tmp/mpld MPLBACKEND= python  # make sure we have a default config
Python 3.7.1 (default, Oct 22 2018, 10:41:28) 
[GCC 8.2.1 20180831] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib.figure, sys
>>> [m for m in sys.modules if m.startswith("matplotlib._")]
['matplotlib._color_data', 'matplotlib._version', 'matplotlib._pylab_helpers', 'matplotlib._mathtext_data', 'matplotlib._png', 'matplotlib._path', 'matplotlib._cm', 'matplotlib._cm_listed', 'matplotlib._image', 'matplotlib._contour', 'matplotlib._layoutbox', 'matplotlib._constrained_layout', 'matplotlib._tri', 'matplotlib._qhull']

Out of interest, do you have a number for how much time this will save?

It's not really easy to read the whole thing, but the flamegraph in #11546 doesn't seem to indicate that these imports are particularly significant, except maybe the urllib one you have downstream. Importing NumPy seems to dominate by a fair fair bit, unless you've already tackled that one?

@anntzer wrote:

Just importing matplotlib.figure (which is necessary if you want to do anything with matplotlib, I'm not even talking about pyplot) already imports these extension modules,

Have you tried it with this PR though?

@ImportanceOfBeingErnest wrote:

Out of interest, do you have a number for how much time this will save?

When importing matplotlib in pyodide, the import time goes from 5.9s to 5.2s (when added with a few others that involve non-underscore-prefixed-but-probably-not-intentionally-public things). This is largely due to the slowness of dynamically linking extension modules on the WebAssembly platform. I would expect the delta on a native platform to be much smaller. (See pyodide/pyodide#251).

@QuLogic wrote:

It's not really easy to read the whole thing, but the flamegraph in #11546 doesn't seem to indicate that these imports are particularly significant

Things change when the cost of importing extension modules is higher. Particularly the _qhull and _tri modules stand out more in that context.

Raw data: https://gist.github.com/mdboom/3d5d86e217f8f650f33a85a39cd835cc

But, yes, I would be a big win to not import urllib as well.

I haven't tackled numpy, but I would consider that something that probably needs to be dealt with in numpy. Lazy importing all of numpy for matplotlib seems unfeasible.

@anntzer: I've added a test here to ensure this "sticks". It can easily be extended in the future if we want to "blacklist" more modules for lazy loading.

This also gave me the opportunity to measure on a native build. As expected, it's pretty minor: 251424 vs 281676 us.

Have you tried it with this PR though?

Duh, sorry :)

Thanks for the test.

Would also lazy loading urllib also be acceptable? That's the next piece of low-hanging fruit. It's not underscore-prefixed, but hopefully no one is doing from matplotlib.cbook import urllib. (Famous last words, I know).

I did try inlining urllib imports in #11546 (comment) and actually saw no improvements (despite what the flamegraph says).
If you have numbers that do show improvements with urllib in your case, making the import lazy sounds fine to me.

This is passing CI and ready to merge.

I can confirm that urllib.request not imported anymore with a standard import matplotlib in this PR.

@mdboom Took the liberty of rebasing and force-pushing, hope you do not mind.

This has some real test errors. Presumably missing imports?

Looks like I missed one on the rebase, fixed now.