In #98, I added rustworkx as a backend for the graph state simulator, but sadly, the performance improvement was subtle.
I think this is because most of the optimization process is done in pattern.py, not in GraphState.
Refactoring the code might improve the performance. For example, the following code searches all the command sequences to find the measurement command, but we can make a list of indices where the measurement commands are stored during the pattern standardization and save it as an attribute in the Pattern class.
In #98, I added
rustworkx
as a backend for the graph state simulator, but sadly, the performance improvement was subtle. I think this is because most of the optimization process is done inpattern.py
, not inGraphState
.Refactoring the code might improve the performance. For example, the following code searches all the command sequences to find the measurement command, but we can make a list of indices where the measurement commands are stored during the pattern standardization and save it as an attribute in the
Pattern
class.https://github.com/TeamGraphix/graphix/blob/8313d3c773c71920836b5cd1ac2ce1a485e7a1ad/graphix/pattern.py#L1792-L1801
It also scans the whole command sequence twice, which looks redundant.
https://github.com/TeamGraphix/graphix/blob/8313d3c773c71920836b5cd1ac2ce1a485e7a1ad/graphix/pattern.py#L1806-L1808
Another suggestion is to use JIT compiler (e.g. numba, jax). Wrapping frequently called functions by jit may improve performance.