Leverage rustworkx node and edge count hints in transpiler

[mtreinish]

Summary

This commit updates the DAGCircuit construction in the transpiler to use the newly introduced node_count_hint and edge_count_hint kwargs on the rustworkx graph constructors. In situations where we know the size of the dag or at least the lower bound we can reduce the number of underlying memory allocations by preallocating that size when we create the inner graph object. This commit adds private arguments to the DAGCircuit constructor which are used to provide these size hints to rustworkx.

Details and comments

[qiskit-bot]

One or more of the following people are relevant to this code:

• @Qiskit/terra-core
• @levbishop

[coveralls]

Pull Request Test Coverage Report for Build 10150963487

Details

• 26 of 27 (96.3%) changed or added relevant lines in 8 files are covered.
• 15 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-0.008%) to 89.767%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/synthesis/one_qubit/one_qubit_decompose.py	0	1	0.0%

Files with Coverage Reduction	New Missed Lines	%
qiskit/transpiler/passes/synthesis/unitary_synthesis.py	2	88.39%
crates/qasm2/src/lex.rs	6	92.37%
qiskit/synthesis/two_qubit/xx_decompose/decomposer.py	7	90.84%

Totals
Change from base Build 10150038699:	-0.008%
Covered Lines:	66971
Relevant Lines:	74605

---

💛 - Coveralls

[ElePT]

The use of count hints looks straightforward to me. I would have to look into the passes better to fully get where some of the counts are coming from, but I guess that there isn't any big issue if the tests pass.

[ElePT]

Usual question for me, how did you reach a node count (hint) of 3*num_qubits here?

[mtreinish]

The dagcircuit being built here is taking a n qubit barrier and splitting it into n 1 qubit barriers so we can compute the connected components of the circuit. So if it's a 3q barrier it would looks something like:

So there are 3 nodes for every qubit and 2 edges.

[jakelishman]

In general this seems like a good idea. There's a few places where the amount of calculation / private-method accessing we're doing is sufficiently high that it might not be worthwhile in Python space, but I don't feel strongly.

The hints in copy_empty_like feel a bit more awkward - they make sense in in the context of copy or if the DAG will be refilled, but for things like layers, the overallocation feels like it could get quite out-of-hand.

[jakelishman]

Should copy_empty_like eagerly allocate to the full size? Feels like that could be overallocating a bit. Maybe we want to control it with a single flag?

[jakelishman]

I'm suspicious that the Python-space time to calculate this stuff is quite possibly similar to the Rust-space time to just grow the vectors.

[mtreinish]

Yeah, I was worried about this too. In practice I think the list is only ever a single list entry here though. The code handles disjoint connectivity, but iirc it was unsound to do the routing split up so we bail return an unrouted circuit before this gets called if the number of components is >1.

[jakelishman]

I'm fine to just leave it anyway - it's probably just going to be a wash at worst, rather than hurting.

[mtreinish]

I'm going to close this as it's no longer relevant since we've moved the DAGCircuit to rust. There might still be places we want to do this from python but the implementation will have to be added as part of the rust implementation of the dag now.