Welcome to matplotlib development and thanks for your contribution.
You've found a good performance improvement!

Comparing different types costs extra time as the following tests show:

native (int, np.int64)

In [16]: %%timeit ref = 5
    ...: for i in np.arange(1_000_000):
    ...:     if i == ref:
    ...:         continue
    ...:     
887 ms ± 49.6 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

int reference, np.uint8 array:

In [17]: %%timeit ref = 5
    ...: for i in np.arange(1_000_000, dtype=np.uint8):
    ...:     if i == ref:
    ...:         continue
    ...:     
4.59 s ± 87.1 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

np.uint8 reference, np.uint8 array:

In [18]: %%timeit ref = np.uint8(5)
    ...: for i in np.arange(1_000_000, dtype=np.uint8):
    ...:     if i == ref:
    ...:         continue
    ...:     
443 ms ± 23.8 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

np.uint64 reference, np.uint64 array:

In [19]: %%timeit ref = np.uint64(5)
    ...: for i in np.arange(1_000_000, dtype=np.uint64):
    ...:     if i == ref:
    ...:         continue
    ...:     
475 ms ± 36.8 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

codes seem to be always uint8 (there's a class variable Path.code_type, which is unfortunately public, but most likely only intended for reading not for writing. Also the Path docstring says codes should be utf8). I recommend changing Path.STOP and Path.NUM_VERTICES_FOR_CODE to this type to avoid casting the individual elements at all, which should make the code even a bit more faster.

Thanks for the benchmarks, using uint8 seems much faster indeed.

Small question, do you mean adjusting Path.STOP, or only casting it in iter_segments(). The former would make many things using the constants faster everywhere I guess, but I'm not sure regarding compatibility.

edit: I've pushed the direct change for starters.

Yes, I meant the direct change.

I'm 99% sure about compatibility. uint8 can drop in wherever you expect an int and the predefined constants are small enough and don't change so that we don't have to worry about overflows. Even if somebody should extend this with own implementations and use int, everything should still work.

We should probably add an API change note to be on the safe side.

That said, I'd still want the opinion of other devs on this.

We should probably add an API change note to be on the safe side.

I've added something to next_api_changes

Out of curiosity, have you benchmarked the new version?

Only using wire3d_animation_sgskip + pycairo, see the PR summary and commits. (best out of 5 each time)