Port the count_ops method in QuantumCircuit to Rust

[melechlapson]

Summary

This PR is to address issue 12971 to port the count_ops method into Rust to improve performance.

Details and comments

I added a count_ops method to the CircuitData class in qiskit/crates/circuit/src/circuit_data.rs and updated the count_ops method in qiskit/circuit/quantumcircuit.py to call CircuitData's count_ops method.

[coveralls]

Pull Request Test Coverage Report for Build 10636776886

Details

• 10 of 10 (100.0%) changed or added relevant lines in 2 files are covered.
• 16 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.01%) to 89.147%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/lex.rs	4	92.48%
crates/qasm2/src/parse.rs	12	97.15%

Totals
Change from base Build 10636396685:	-0.01%
Covered Lines:	71827
Relevant Lines:	80571

---

💛 - Coveralls

[melechlapson]

For a simple 2 qubit system in superposition, benchmarking shows ~3x improvement in performance on average. For a much larger, more complex circuit the improvement was ~9x.

Name (time in us)                                   Min                   Max                Mean              StdDev              Median                IQR            Outliers  OPS (Kops/s)            Rounds  Iterations
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
test_new_count_ops_benchmark                     3.4159 (1.0)         21.2500 (1.0)        3.6377 (1.0)        0.6866 (1.0)        3.6249 (1.0)       0.0421 (1.0)         4;187      274.9019 (1.0)        1000           1
test_old_count_ops_benchmark                    10.0830 (2.95)       150.8750 (7.10)      11.2112 (3.08)       6.2859 (9.16)      10.7500 (2.97)      0.4580 (10.87)        7;27       89.1962 (0.32)       1000           1
test_new_count_ops_benchmark_large_circuit      59.9581 (17.55)      147.6670 (6.95)      65.9430 (18.13)      7.9297 (11.55)     64.3330 (17.75)     3.7500 (88.98)       62;73       15.1646 (0.06)       1000           1
test_old_count_ops_benchmark_large_circuit     529.9998 (155.16)   5,656.8750 (266.21)   593.9564 (163.28)   317.4110 (462.32)   567.1044 (156.45)   29.7080 (704.94)       8;59        1.6836 (0.01)       1000           1
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

[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 following people are relevant to this code:

• @Qiskit/terra-core
• @kevinhartman
• @mtreinish

[mtreinish]

This looks good, thanks for doing this. I just have a few inline suggestions. After you apply them you might want to rerun the benchmarking too to see how it impacts the runtime performance of the method.

[mtreinish]

This doesn't need to be &mut because we're not mutating self here. So you can just use &self

[mtreinish]

You don't actually need to build the OperationRef view here, PackedOperation has a name method you can just call. This is actually what I think blocked you from returning a &str as the key before.

Suggested change

	.entry(instruction.op.view().name().to_string())
	.entry(instruction.op.name().to_string())

[melechlapson]

Ah for some reason I didn't see that and that made things more complicated for me

[mtreinish]

I'm not actually suggesting you make this change, as I think a for loop is probably more legible. But I was curious if you could do this with just an iterator which you can do like this:

Suggested change

	let mut ops_count: IndexMap<String, usize, ::ahash::RandomState> = IndexMap::default();
	for instruction in &self.data {
	*ops_count
	.entry(instruction.op.view().name().to_string())
	.or_insert(0) += 1;
	}
	let mut ops_count =
	self.data
	.iter()
	.fold(IndexMap::default(), |mut ops_count, instruction| {
	*ops_count.entry(instruction.op.name()).or_insert(0) += 1;
	ops_count
	});

I don't think there is any advantage to writing it like this. So it's more just an interesting musing on how to use functional programming style iterators for this.

[melechlapson]

I'll test it out

[melechlapson]

seemed to work

[mtreinish]

LGTM, thanks for doing this.