Improve performance of measure_all by inlining calls to barrier

[eendebakpt]

Summary

Improve performance of measure_all by inlining calls to barrier

Details and comments

Benchmark:

import time
from qiskit.circuit import QuantumCircuit
def g():
    qc=QuantumCircuit(2)
    qc.measure_all()

x=[]
for ii in range(20):
    t0=time.time()
    for ii in range(1000):
        g()
    dt=time.time()-t0
    #print(dt)
    x.append(dt)
    
print(f'total: {sum(x):.2f} seconds')

Results:

main: total: 2.04 seconds
PR: total: 1.80 seconds

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the the following people are requested to review this:

• @Qiskit/terra-core

[coveralls]

Pull Request Test Coverage Report for Build 7045795400

• 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
• 17 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.02%) to 87.416%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/lex.rs	5	91.67%
crates/qasm2/src/parse.rs	12	96.67%

Totals
Change from base Build 7039950767:	-0.02%
Covered Lines:	59749
Relevant Lines:	68350

---

💛 - Coveralls

[jakelishman]

This PR has the same considerations as #11008 (and tbh, it might be easier to combine them - they're touching the same code with the same intent).

[jakelishman]

I've just pushed up b4ff01e to correct the use of the fast path constructors both in normal cases and in the case of control-flow scopes. That also had the effect of inlining the measurements, so it's good for about another ~20% speedup on the timings at the top of this PR comment.

Since I pushed up a non-trivial amount of code to the PR, it'll need an alternate reviewer now.

[eendebakpt]

I've just pushed up b4ff01e to correct the use of the fast path constructors both in normal cases and in the case of control-flow scopes. That also had the effect of inlining the measurements, so it's good for about another ~20% speedup on the timings at the top of this PR comment.

Since I pushed up a non-trivial amount of code to the PR, it'll need an alternate reviewer now.

@jakelishman This PR still needs an update to current main. Do you want me to pick this up?

[jakelishman]

It's ok, thanks - it's not a problem that it's not updated to main, because part of our merge train will cause it to get automatically updated. Unfortunately, I've broken the tests with my changes because I didn't test in enough detail, so that's my fault and I'll just fix it up quickly.

[jakelishman]

It transpires that the test failure is because of (imo severe) problems with NLocal via BlueprintCircuit, and I'm amazed it worked in any way before now. The principle is that any subclass of BlueprintCircuit is fundamentally unsafe to general mutation, because if the "build" gets invalidated (e.g. here by adding a register), then the circuit is incredibly susceptible to being rebuilt completely out-of-order:

from qiskit.circuit.library import RealAmplitudes, XGate
from qiskit.circuit import CircuitInstruction, ClassicalRegister

qc = RealAmplitudes(num_qubits=2, reps=2)
qc.add_register(ClassicalRegister(2, "meas"))
qc._append(CircuitInstruction(XGate(), (qc.qubits[0],), ()))
qc.draw()

        ┌───┐┌────────────────────────────────────────────────┐
   q_0: ┤ X ├┤0                                               ├
        └───┘│  RealAmplitudes(θ[0],θ[1],θ[2],θ[3],θ[4],θ[5]) │
   q_1: ─────┤1                                               ├
             └────────────────────────────────────────────────┘
meas: 2/═══════════════════════════════════════════════════════

That's a problem with BlueprintCircuit in general, though, so best fix it in another issue (I can potentially do that).

[jakelishman]

Ok, said fix is in #11181, which this PR is now blocked on. It turns out that the original iteration of this PR also triggered the bug of #11180, but because it was only Barrier that was using the _append call, it wasn't detected.

[eendebakpt]

Closing in favor of #11345