Skip to content

Conversation

@wshanks
Copy link
Collaborator

@wshanks wshanks commented Nov 24, 2025

qiskit_aer and scipy were eagerly imported in the utils.json module (with fallbacks for when they were not installed) which is imported along with import qiskit_ibm_runtime. Here these imports are delayed until JSON serialization or deserialization are attempted. In the serialization case, the packages would have already been imported before objects from them would need to be serialized any way.

Avoiding these imports saves roughly half a second (but the number depends on the computer running the test).

`qiskit_aer` and `scipy` were eagerly imported in the `utils.json` module
(with fallbacks for when they were not installed) which is imported
along with `import qiskit_ibm_runtime`. Here these imports are delayed
until JSON serialization or deserialization are attempted. In the
serialization case, the packages would have already been imported before
objects from them would need to be serialized any way.

Avoiding these imports saves roughly half a second (but the number
depends on the computer running the test).
@wshanks
Copy link
Collaborator Author

wshanks commented Nov 24, 2025

I don't have any urgency for merging this. It was something I noticed while debugging qiskit-experiments' imports (that scipy and qiskit-aer were hardly used but eagerly imported), so I thought I would see what it looks like to avoid importing them.

By the way, deserialization of spmatrix was using scipy without a guard. I am not sure if that even comes up in practice any more but I put in a guard like the qiskit-aer case had.

Copy link
Collaborator

@ihincks ihincks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice thinking! I have not done any investigating yet about whether this would fit in qiskit-ibm-runtime specifically, but I'm wondering if any of qiskit's tooling for optionals might help us here, or if you think it would be better to just do it manually as this PR currently implements?

I found it convenient in samplomatic to declare consts of optional dependencies and to use them.

@wshanks
Copy link
Collaborator Author

wshanks commented Nov 26, 2025

The problem with the Qiskit tooling is that it is aimed at avoiding import errors for optional dependencies that might not be installed. For the serialization code modified in this PR, we are trying to avoid importing a package that is installed but is not needed. The serialization code is going through a big list of tests to see which kind of object the current one is and use its serialization method. For Aer and Scipy, it wants to check the object with isinstance with classes from Aer/Scipy but that requires importing the packages. If the object turns out not to be one related to those packages, then we imported them unnecessarily for the check. What I realized was that if the isinstance check is going to be true, that object must already have been made by user code that imported the package so we should be able to check in sys.modules before trying the import.

(We probably don't need to worry about it but I could imagine some clever code that implements the spmatrix or NoiseModel interface without actually subclassing the class and then somehow registering the class so that isinstance still works without importing the other package. Even doing that though, roundtrip serialization would revert back to the normal class and not the custom one).

We could use the Qiskit tooling on the deserialization part. We already have to try the import right away in that case. As Qiskit has narrowed its focus over the recent years into 1.0 and 2.0, I have been more hesitant to use features that are not related to the primary focus of quantum circuit building but LazyImportTester is publicly documented and would give better error messages.

I also don't feel that strongly against using the lazy tester in serialization code. It would still avoid the import time hit on import qiskit_ibm_runtime but it would lead to taking the hit (usually unnecessarily, I think) on first job submission.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants