Speed up hashing for GridQubit, LineQubit, and NamedQubit

[maffoo]

This speeds up hashing on GridQubit, GridQid, LineQubit, and LineQid. Instead of using _compat.cached_method, we store an explicit self._hash property to cache computing the hash. We also make the constructors explicit in the concrete classes with no need to call a subperclass constructor. We did some basic benchmarks to compare performance with current master. On this branch GridQubit.__hash__ dropped from 1.3us to 488ns (2.66x speedup), while repeated hashing of the same grid qubit dropped from 150ns to 121ns (1.24x speedup). Similarly, LineQubit.__hash__ dropped from 685uns to 453ns (1.51x speedup), while repeated hashing of the same line qubit dropped from 142ns to 124ns (1.15x speedup).

On master:

In [2]: gq = cirq.GridQubit(1, 2)

In [3]: %timeit hash(gq)
150 ns ± 1.66 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

In [4]: %timeit hash(cirq.GridQubit(1, 2))
1.3 µs ± 25.2 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

In [5]: lq = cirq.LineQubit(3)

In [6]: %timeit hash(lq)
142 ns ± 2.85 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

In [7]: %timeit hash(cirq.LineQubit(3))
685 ns ± 14.1 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

and on this branch:

In [2]: gq = cirq.GridQubit(1, 2)

In [3]: %timeit hash(gq)
121 ns ± 0.737 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

In [4]: %timeit hash(cirq.GridQubit(1, 2))
488 ns ± 2.16 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

In [5]: lq = cirq.LineQubit(3)

In [6]: %timeit hash(lq)
124 ns ± 1.53 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

In [7]: %timeit hash(cirq.LineQubit(3))
453 ns ± 2.19 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (3c81961) 97.84% compared to head (c43f689) 97.84%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #6350   +/-   ##
=======================================
  Coverage   97.84%   97.84%           
=======================================
  Files        1110     1110           
  Lines       96656    96696   +40     
=======================================
+ Hits        94572    94612   +40     
  Misses       2084     2084           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[maffoo]

Updated to optimized NamedQubit as well; first-time hashing sped up from 1.78us to 553ns (3.2x speedup) and repeated hashing sped up from 220ns to 162ns (1.36x speedup).

On master:

In [2]: nq = cirq.NamedQubit("abc")

In [3]: %timeit hash(nq)
220 ns ± 14.1 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

In [4]: %timeit hash(cirq.NamedQubit("abc"))
1.78 µs ± 13.9 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

On this branch:

In [2]: nq = cirq.NamedQubit("abc")

In [3]: %timeit hash(nq)
162 ns ± 4.14 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

In [4]: %timeit hash(cirq.NamedQubit("abc"))
553 ns ± 1.16 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

[dstrain115]

Should we just compute this in the constructor? It should be immutable, right? That would remove the need for an if statement.

[maffoo]

We could, but since construction is more common than hashing I think it would be good to keep the constructor as fast as possible. I played around a bit with adding a __new__ method so we can actually cache instances instead of allocating new ones each time the constructor is called, but that interacts with pickling in strange ways that I haven't worked out yet.

[maffoo]

Here's a comparison of timings with lazy hashing (this PR) vs eager hashing where as you suggest the hash is computed in the constructor and there's no conditional in __hash__. It does indeed make hashing faster, but slows down the constructor quite a bit:

Operation	Lazy Hash [ns]	Eager Hash [ns]	t_eager / t_lazy
%timeit cirq.GridQubit(1, 2)	294	430	1.46x
%timeit hash(cirq.GridQubit(1, 2))	652	589	0.90x
q = cirq.GridQubit(1, 2); %timeit hash(q)	163	135	0.83x
%timeit cirq.LineQubit(3)	254	369	1.45x
%timeit hash(cirq.LineQubit(3)	560	506	0.90x
q = cirq.LineQubit(3); %timeit hash(q)	163	144	0.88x
%timeit cirq.NamedQubit("abc")	249	361	1.45x
%timeit hash(cirq.NamedQubit("abc")	568	502	0.88x
q = cirq.NamedQubit("abc"); %timeit hash(q)	159	137	0.86x

So eager hashing speeds up the __hash__ calls by between 10-20%, but slows down the constructors by almost 50%. If we can figure out __new__ to cache qid instances, then I think eager hashing would be a clear win, but for now I'd suggest we stick with lazy.

[dstrain115]

Ok, thanks for the thorough analysis. This makes sense.