Skip to content
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

Some test modules (at least one) take a long time to import #7914

Closed
mtreinish opened this issue Apr 8, 2022 · 2 comments · Fixed by #8885
Closed

Some test modules (at least one) take a long time to import #7914

mtreinish opened this issue Apr 8, 2022 · 2 comments · Fixed by #8885
Labels
bug Something isn't working mod: fake_provider Related to the fake_provider module and fake backends

Comments

@mtreinish
Copy link
Member

Environment

  • Qiskit Terra version: main
  • Python version: 3.10
  • Operating system: Linux

What is happening?

Some test modules (maybe just one) take a long time to import. I've generally noticed that test discovery in stestr (which scans the test/python directory and imports every module named test_*) has been getting increasingly slow lately. When working on #7912 in particular I found that importing test.python.providers.test_fake_backends alone takes 13sec to import. I assume this is ddt and other module level processing that is happening when it is imported. This is problematic especially when importing this one file takes ~20% of the time a full test run takes for me locally. There are likely other offenders in the test suite causing a similar slowdown.

How can we reproduce the issue?

python -c "test.python.providers.test_fake_backends"

What should happen?

The import should be faster

Any suggestions?

No response

@mtreinish mtreinish added the bug Something isn't working label Apr 8, 2022
@mtreinish
Copy link
Member Author

Taking a quick look at this most of the time is being spent dealing with pulse defaults. Importing test.python.providers.test_fake_backends:

Screenshot_2022-05-03_11-56-38

is spending most of the time constructing the pulse objects for the default calibrations in the Target. We either need to speed this up or subclass InstructionProperties for the fake backends to lazy load pulse calibrations on first access so we only take the performance hit when we're using it.

@mtreinish mtreinish added the mod: fake_provider Related to the fake_provider module and fake backends label May 3, 2022
@jakelishman
Copy link
Member

Probably we need to solve it more at the source, otherwise we're going to make life more difficult for downstream providers as well - they'll be forced into a design model where they (at least) construct their Backend instances lazily when requested through get_backend, rather than letting them build a cache on Provider instantiation. Probably that's not so huge, but it's an annoyance in the path of BackendV2 adoption.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working mod: fake_provider Related to the fake_provider module and fake backends
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants