I also did the timing myself, which I don't fully understand since the import without the modification of this PR has some additional import delay directly in the matplotlib base package.

If you've recently modified some files (editing or switching branches, etc.), then be careful to run the test at least twice. The first import can be slowed down by updating of the bytecode files.

@QuLogic Thanks for the hint. I ran each code three times and just posted the result of the third run.

Anyway, the result shows that pyparsing is not imported and thus importing rcsetup is fast. And that's the goal of the PR.

This looks good. If pyparsing is such a heavy lift is there something lighter than can be imported?

I'd like to ultimately get rid of fontconfig patterns altogether (#10249), but incremental improvements are fine in the meantime.
I don't think this really helps with any realistic import time though, as you'll also import mathtext (through e.g. backend_agg, or any other backend) which also imports pyparsing? IOW you need to also delay the import in mathtext to get useful import-time benefits I think?

👍 in principle, agree that incremental improvements are worth doing, but also agree with @anntzer that this may be un-done by the mathtext import. It maybe better to time importing pyplot (with Agg as the backend)?

or something like matplotlib.figure + matplotlib.backend_bases, which should be the absolute minimum needed to do anything (e.g. using a third-party (hemhem :)) backend).

Ok, here's the import timing of

python3.7 -X importtime -c "import matplotlib.pyplot as plt; plt.use('agg')" 2> matplotlib.log

As one can see, there's still no pyparsing import. Of course, this PR is "just" a 5% improvement, but it works as is.

Really wondering what the big gap in matplotlib is doing.

My guess at the big delay is versioneer calling git via subprocess. That only happens in the dev install, if you 'properly' install it that call is replaced by a string lookup.

I don't know why it doesn't show up in -Ximporttime output, but pyparsing is actually still being imported: this can be checked by printing out sys.modules; or one can just also check that backend_agg imports mathtext, which imports pyparsing...

Does this mean, this PR will have no effect despite the importtime results?

What's exactly happening is a bit mysterious to me too, but I'm just reporting my observations...

No idea how to investigate this further.

So, either we merge this and hope that it has some effect, or we simply close the PR. Both would be fine for me.

I would prefer we figure out what's happening before taking further action either way...

Do you have any idea what to check?

nothing right now

Added the needs revision tag based on the discussion above as I'm not actually convinced this works, but again I'm not really sure what's exactly happening here.

I just rebased this on master and tried it out, but it does not seem to have any effect on overall import time. The rcsetup -> fontconfig_pattern part of the tree is indeed faster, but the overall matplotlib section remains the same.

Edit: I forget to do a non-editable install like @tacaswell mentioned, but while a bit quicker, it's still not really affected by this PR.

Rebased so that it's easier to look into this further.

AFAICS there are the following additional ways we import pyparsing:

• in _check_versions(). IMHO this could be delayed (or dropped? - we ensure at least 2.0.1, which was released in 2013).
• via the following import sequence

  import matplotlib.pyplot as plt
  -> import matplotlib.colorbar
  -> import matplotlib.contour as contour
  -> import matplotlib.text as text
  -> from .textpath import TextPath
  -> from matplotlib.mathtext import MathTextParser
  -> from pyparsing import (
  

Technical note: I've patched sys.modules at the top of __init__.py to get notifed when a pyparsing import is requested. - Not sure if it's the best way to do it, but it got me the above info 😄

from collections.abc import MutableMapping
import sys
import traceback


class LogDict(MutableMapping):

    def __init__(self, d):
        self.d = d

    def __getitem__(self, name):
        if 'pyparsing' in name:
            print(f'\n\nget {name}')
            traceback.print_stack()
        return self.d[name]

    def __setitem__(self, name, val):
        self.d[name] = val

    def __delitem__(self, name):
        del self.d[name]

    def __iter__(self):
        return iter(self.d)

    def __len__(self):
        return len(self.d)


sys.modules = LogDict(sys.modules)

AFAICT, recent versions of pyparsing now import much faster, and now only contribute <2% of the total import time. Unless others can repro the original problem, I propose to close this.

I still get a significant contribution (27%) from pyparsing 3.0.6. But my dev environment is a bit older overall. Maybe I should test with a fresh setup.

OTOH, I likely won't come back to this any time soon.

FTR this is what I get as of master:

Interestingly, your timings and import sequence is completely different from mine.

Did you use python3.7 -X importtime -c "import matplotlib.pyplot as plt; plt.use('agg')" 2> matplotlib.log like the old examples? I did.

What's more disturbing is that were now 0.1-0.2s slower overall. But execution timing is a difficult topic and I don't want to go that rabbit hole here for now.