Speed up ConsolidateBlocks pass

[mtreinish]

What should we add?

When running a large transpile() (with 1k circuit qubits) with optimization level 3 a substantial amount of time, ~32%, of the compilation is spent in the ConsolidateBlocks pass. For something that's supposed to take a block of gates on 2 qubit and replace it with an equivalent UnitaryGate this is a larger portion of time than would normally be expected. Looking at the profile:

Most of the time seems to be spent in the Operator object creation. We had similar performance issues around the use of Operator to compute unitaries in Optimize1qGatesDecomposition and we moved to computing the matrix directly (which is admittedly easier to do for 1q) and sped up the pass significantly (see #5909). We should look at doing a similar optimization in ConsolidateBlocks and fall back to using Operator if there are gates in the block we can't work directly with a matrix on.

[jakelishman]

A slight alternative of course is to speed up the Operator constructor path. There's no real reason that we should be calling QuantumCircuit.to_instruction to handle circuits (which I'm pretty sure involves a deepcopy), and then unwrapping the instructions back down to its definition again.

That said, the extra overhead the Operator class has (in things like qargs construction, and so using einsum instead of straight matmul) is still probably going to be way too high.

[raynelfss]

Me and danielleodigie are interested in looking into this issue. Can we be assigned?

[jakelishman]

@danielleodigie: because of GitHub weirdness, it's tricky for us to formally assign you unless you comment on this issue.

[danielleodigie]

oops I didn't know that, I'd like to be assigned too!

[jakelishman]

No worries - it's just one of those weird little GitHub things. Maybe it's to avoid people spamming famous people by assigning them on random little repos? I dunno.