Environment

• Qiskit Terra version: main (after 05b60a5 )
• Python version: 3.8
• Operating system: linux

What is happening?

The nightly benchmark runs have flagged several run time performance regressions after #7087 merged:

• https://qiskit.github.io/qiskit/#passes.MultiQBlockPassBenchmarks.time_collect_multiq_block?cpu=Intel(R)%20Xeon(R)%20E-2174G%20CPU%20%40%203.80GHz&machine=qiskit-benchmarking01&num_cpu=8&os=Ubuntu%2020.04&ram=64GB&python=3.8&p-n_qubits=20&p-depth=1024&p-max_block_size=2&commits=05b60a5e
• https://qiskit.github.io/qiskit/#passes.PassBenchmarks.time_remove_diagonal_gates_before_measurement?cpu=Intel(R)%20Xeon(R)%20E-2174G%20CPU%20%40%203.80GHz&machine=qiskit-benchmarking01&num_cpu=8&os=Ubuntu%2020.04&ram=64GB&python=3.8&p-n_qubits=14&p-depth=1024&commits=05b60a5e
• https://qiskit.github.io/qiskit/#passes.PassBenchmarks.time_remove_reset_in_zero_state?cpu=Intel(R)%20Xeon(R)%20E-2174G%20CPU%20%40%203.80GHz&machine=qiskit-benchmarking01&num_cpu=8&os=Ubuntu%2020.04&ram=64GB&python=3.8&p-n_qubits=20&p-depth=1024&commits=05b60a5e
• https://qiskit.github.io/qiskit/#passes.PassBenchmarks.time_optimize_swap_before_measure?cpu=Intel(R)%20Xeon(R)%20E-2174G%20CPU%20%40%203.80GHz&machine=qiskit-benchmarking01&num_cpu=8&os=Ubuntu%2020.04&ram=64GB&python=3.8&p-n_qubits=20&p-depth=1024&commits=05b60a5e
• https://qiskit.github.io/qiskit/#passes.PassBenchmarks.time_collect_2q_blocks?cpu=Intel(R)%20Xeon(R)%20E-2174G%20CPU%20%40%203.80GHz&machine=qiskit-benchmarking01&num_cpu=8&os=Ubuntu%2020.04&ram=64GB&python=3.8&p-n_qubits=20&p-depth=1024&commits=05b60a5e
• https://qiskit.github.io/qiskit/#assembler.AssemblerBenchmarks.time_assemble_circuit?cpu=Intel(R)%20Xeon(R)%20E-2174G%20CPU%20%40%203.80GHz&machine=qiskit-benchmarking01&num_cpu=8&os=Ubuntu%2020.04&ram=64GB&python=3.8&p-n_qubits=1&p-depth=4096&p-number%20of%20circuits=1&commits=05b60a5e
• https://qiskit.github.io/qiskit/#passes.MultiQBlockPassBenchmarks.time_collect_multiq_block?cpu=Intel(R)%20Xeon(R)%20E-2174G%20CPU%20%40%203.80GHz&machine=qiskit-benchmarking01&num_cpu=8&os=Ubuntu%2020.04&ram=64GB&python=3.8&p-n_qubits=14&p-depth=1024&p-max_block_size=1&commits=05b60a5e
• https://qiskit.github.io/qiskit/#passes.MultiQBlockPassBenchmarks.time_collect_multiq_block?cpu=Intel(R)%20Xeon(R)%20E-2174G%20CPU%20%40%203.80GHz&machine=qiskit-benchmarking01&num_cpu=8&os=Ubuntu%2020.04&ram=64GB&python=3.8&p-n_qubits=20&p-depth=1024&p-max_block_size=3&commits=05b60a5e
• https://qiskit.github.io/qiskit/#passes.MultipleBasisPassBenchmarks.time_basis_translator?cpu=Intel(R)%20Xeon(R)%20E-2174G%20CPU%20%40%203.80GHz&machine=qiskit-benchmarking01&num_cpu=8&os=Ubuntu%2020.04&ram=64GB&python=3.8&p-n_qubits=5&p-depth=1024&p-basis_gates=%5B'rx'%2C%20'ry'%2C%20'rz'%2C%20'r'%2C%20'rxx'%2C%20'id'%5D&commits=05b60a5e

none are huge in absolute time (on the order of ms) and likely won't be noticeable in a larger transpile() call or application but we should try to fix these because #7087 really shouldn't have had any performance impact.

How can we reproduce the issue?

Run any of the transpiler passes identified in the regressions linked

What should happen?

The addition of a new abstract class defining the interface for a circuit operation shouldn't cause a noticeable performance regression

Any suggestions?

Identify where the passes are spending more time after the addition of the Operation class and fix the bottleneck.