Thanks for the analysis! It's really nice to see how the imports run.

urllib.requests could probably be inlined. It's only used in _open_file_or_url() - apart from tests.

pyparsing is a bit more difficult. It's used in FontconfigPatternParser.__init__(), which is executed at startup and is used for validating rc settings. So lazy-loading does not work because we need it at startup.

Generally, I'm not sure if we want to move imports to local contexts to scrap of a few milliseconds from importing matplotlib. That's for someone else to decide @tacaswell .

Note that support for directly loading from urls was added in #4256 with the following motivation:

I suppose I also should have commented on the motivation here. In Python 2, you could do something like the following to download an image from the internet:
plt.imread( urllib2.urlopen(url))
I noticed that for some reason with my Linux-based Python installations, the following call signature would break in Python 3:
plt.imread(urllib.request.urlopen(url))
However, the following does work in Python 3:
plt.imread(io.BytesIO(urllib.request.urlopen(url).read()))
It seems like rather than having the users tinker with trying to get the proper call signature for their system and python version, it might be more straightforward to implement the logic in imread to handle URLs directly.

which simply doesn't apply anymore today. I would thus like to suggest at least considering deprecating this functionality.

Also, a simple inlining of the import did not clearly yield measurable improvements to import time in a quick experiment, so some measurements (not necessarily in depth) actually establishing the improvement post-inlining would be nice.

There are actually two urllib.request uses:

• The one in matplotlib._open_file_or_url() i mention above.
• The one in matplotlib.image from @anntzer

Just removing or inlineing one does not give a performance benefit.

I did try inlining both.

Edit: Added "Needs confirmation" label as I simply cannot reproduce these numbers (in particular pyparsing imports very quickly for me, and I did try inlining the imports), but of course patches with performance numbers are still welcome.

I played a bit with -Ximporttime and noticed that in certain cases, a module taking longer to import was actually due to the gc kicking in; thus, one should call gc.disable() before doing these benchmarks.

I don't see an action on this, and it looks ephemeral, so I'm closing....