Perf: align_multiple speedup from using typed memoryviews

[jberg5]

Very small change, decent performance impact depending on problem dimensions. Typed memoryviews already existed for code_count; we just weren't using them. Switching lets the indexing run at C speed.

Let's say the length of the alphabet is A, and the number of sequences is N, and the sequence length is L: this indexing was running O(N^2 * A^2) times. So for small L but large A and N the speedup is quite significant. For large L (e.g. cas9, which is what the benchmark uses here

biotite/benchmarks/sequence/align/benchmark_multiple.py

Line 9 in 1fa1b70

fasta_file = fasta.FastaFile.read(data_dir("sequence") / "cas9.fasta")

), other steps of align_multiple dominate, so the wallclock improvement isn't so great.

I had claude run through a number of realistic-looking examples on a c4-standard-8 gcloud vm, this is what it came up with, should give you a sense of how things scale:

┌───────────────┬─────┬──────┬──────────┬─────────┬─────────┐
│    dataset    │  n  │ Lmed │  before  │  after  │ speedup │
├───────────────┼─────┼──────┼──────────┼─────────┼─────────┤
│ kunitz (BPTI) │ 99  │ 53   │ 3087 ms  │ 195 ms  │ 15.9×   │
├───────────────┼─────┼──────┼──────────┼─────────┼─────────┤
│ ig_iset       │ 45  │ 90   │ 690 ms   │ 100 ms  │ 6.9×    │
├───────────────┼─────┼──────┼──────────┼─────────┼─────────┤
│ globin_seed   │ 73  │ 114  │ 1979 ms  │ 398 ms  │ 5.0×    │
├───────────────┼─────┼──────┼──────────┼─────────┼─────────┤
│ pkinase       │ 37  │ 263  │ 915 ms   │ 512 ms  │ 1.8×    │
├───────────────┼─────┼──────┼──────────┼─────────┼─────────┤
│ aldh          │ 84  │ 462  │ 9421 ms  │ 7301 ms │ 1.3×    │
├───────────────┼─────┼──────┼──────────┼─────────┼─────────┤
│ cas9          │ 10  │ 1227 │ 805 ms   │ 770 ms  │ 1.05×   │
├───────────────┼─────┼──────┼──────────┼─────────┼─────────┤
│ globin N=25   │ 25  │ 146  │ 246 ms   │ 69 ms   │ 3.6×    │
├───────────────┼─────┼──────┼──────────┼─────────┼─────────┤
│ globin N=50   │ 50  │ 146  │ 1002 ms  │ 271 ms  │ 3.7×    │
├───────────────┼─────┼──────┼──────────┼─────────┼─────────┤
│ globin N=100  │ 100 │ 146  │ 3999 ms  │ 1071 ms │ 3.7×    │
├───────────────┼─────┼──────┼──────────┼─────────┼─────────┤
│ globin N=200  │ 200 │ 146  │ 16092 ms │ 4209 ms │ 3.8×    │
└───────────────┴─────┴──────┴──────────┴─────────┴─────────┘

So as for "how much faster," the answer is "it depends," but I think in any case this is the right change to make (and if I had to guess is what was intended from the beginning).

[padix-key]

Your are completely right, thanks for the fix!

[codspeed-hq]

Merging this PR will improve performance by 10.31%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
✅ 102 untouched benchmarks
⏩ 14 skipped benchmarks¹

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
⚡	benchmark_match_kmer_selection[BucketKmerTable(10000)-None]	353.3 µs	320.3 µs	+10.31%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing jberg5:align-multiple-memoryview (1693bab) with main (1fa1b70)}

Footnotes

1. 14 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[jberg5]

Test failure is unrelated, #929 should (hopefully) fix it tho!