pauli.evolve() needs a major speedup

What should we add?

@aeddins-ibm found that pauli.evolve() can be quite slow, and we can get substantial performance improvement from using private methods for special cases.

Since pauli.evolve() is the main entry-point / user-interface, it should be fast. There are probably some simple things that can be done to dramatically speed it up. But it needs some profiling to see what’s causing the slowdown.

Here’s a code that shows pauli.evolve() is 10,000x slower than calling _evolve_cx() on individual instructions. Some of this is expected since CX is a special case of clifford. But a) we should have faster ways of dealing with special cases of self-adjoint cliffords and b) is there some other overhead from validation/type-checking?

from qiskit import QuantumCircuit
from qiskit.quantum_info.operators.symplectic.base_pauli import _evolve_cx
from qiskit.quantum_info import Clifford, Pauli, PauliList, random_pauli_list, SparsePauliOp
import time

n = 65
paulis_per_instance = 100
instances = 100

qc = QuantumCircuit(n)
qc.cx(range(n-1),range(1,n))
cliff = Clifford(qc)

result1 = random_pauli_list(n, paulis_per_instance*instances)
result2 = result1.copy()

start = time.time()
result1 = result1.evolve(cliff,frame='s')
print('time using evolve:',time.time()-start)

start = time.time()
for gate in qc.data:
    _evolve_cx(result2, gate[1][0]._index, gate[1][1]._index)
print('time using _evolve_cx:',time.time()-start)

print('same answer?',result1 == result2)

time using evolve: 33.13418793678284
time using _evolve_cx: 0.0023658275604248047
same answer? True

[ajavadia]

nice work @aeddins-ibm !

[aeddins-ibm]

Have to apologize again as there is still an error with the phase (this is a learning exercise for me). I think it’s because I did not yet account for the extra phase from commuting the X gates in the input Pauli object (self) past the Z gates from the stabilizer table (also needed to add self.phase at the end but that’s easier – edited above to include this).

Regarding timing, as written above it was ballpark ~100 times faster than the old evolve, but still ~100 times slower than calling _evolve_cx in a loop. Being somewhere in the middle is perhaps not surprising given that (as others have pointed out) it will be more expensive to process the large N-qubit stabilizer matrix than to process the smaller matrices of the constituent 2-qubit-gates.