rustdoc-search: search backend with partitioned suffix tree

[notriddle]

Before:

• https://notriddle.com/windows-docs-rs/doc-old/windows/
• https://doc.rust-lang.org/1.89.0/std/index.html
• https://doc.rust-lang.org/1.89.0/nightly-rustc/rustc_hir/index.html

After:

• https://notriddle.com/windows-docs-rs/doc/windows/
• https://notriddle.com/rustdoc-html-demo-12/stringdex/doc/std/index.html
• https://notriddle.com/rustdoc-html-demo-12/stringdex/compiler-doc/rustc_hir/index.html

Summary

Rewrites the rustdoc search engine to use an indexed data structure, factored out as a crate called stringdex, that allows it to perform modified-levenshtein distance calculations, substring matches, and prefix matches in a reasonably efficient, and, more importantly, incremental algorithm.

Motivation

Fixes #131156

While the windows-rs crate is definitely the worst offender, I've noticed performance problems with the compiler crates as well. It makes no sense for rustdoc-search to have poor performance: it's basically a spell checker, and those have been usable since the 90's.

Stringdex is particularly designed to quickly return exact matches, to always report those matches first, and to never, ever place new matches on top of old ones. It also tries to yield to the event loop occasionally as it runs. This way, you can click the exactly-matched result before the rest of the search finishes running.

Explanation

A longer description of how name search works can be found in stringdex's HACKING.md file.

Type search is done by performing a name search on each element, then performing bitmap operations to narrow down a list of potential matches, then performing type unification on each match.

Drawbacks

It's rather complex, and takes up more disk space than the current flat list of strings.

Rationale and alternatives

Instead of a suffix tree, I could've used a different approximate matching data structure. I didn't do that because I wanted to keep the current behavior (for example, a straightforward trigram index won't match oepn like the current system does).

Prior art

Sherlodoc is based on a similar concept, but they:

• use edit distance over a suffix tree for type-based search, instead of the binary matching that's implemented here
• use substring matching for name-based search, but not fuzzy name matching
• actually implement body text search, which is a potential-future feature, but not implemented in this PR

Future possibilities

Low-level optimization in stringdex

There are half a dozen low-level optimizations that I still need to explore. I haven't done them yet, because I've been working on bug fixes and rebasing on rustdoc's side, and a more solid and diverse test suite for stringdex itself.

• Stringdex decides whether to bundle two nodes into the same file based on size. To figure out a node's size, I have to run compression on it. This is probably slower than it needs to be.
• Stack compression is limited to the same 256-slot sliding windows as backref compression, and it doesn't have to be. (stack and backref compression are used to optimize the representation of the edge pointer from a parent node to its child; backref uses one byte, while stack is entirely implicit)
• The JS-side decoder is pretty naive. It performs unnecessary hash table lookups when decoding compressed nodes, and retains a list of hashes that it doesn't need. It needs to calculate the hashes in order to construct the merkle tree correctly, but it doesn't need to keep them.
• Data compression happens at the end, while emitting the node. This means it's not being counted when deciding on how to bundle, which is pretty dumb.

Improved recall in type-driven search

Right now, type-driven search performs very strict matching. It's very precise, but misses a lot of things people would want.

What I'm not sure about is whether to focus more on edit-distance-based approaches, or to focus on type-theoretical approaches. Both gives avenues to improve, but edit distance is going to be faster while type checking is going to be more precise.

For example, a type theoretical improvement would fix Iterator<T>, (T -> U) -> Iterator<U> to give Iterator::map, because it would recognize that the Map struct implements the Iterator trait. I don't know of any clean way to get this result to work without implementing significant type checking logic in search.js, and an edit-distance-based "dirty" approach would likely give a bunch of other results on top of this one.

Full-text search

Once you've got this fuzzy dictionary matching to work, the logical next step is to implement some kind of information retrieval-based approach to phrase matching.

Like applying edit distance to types, phrase search gets you significantly better recall, but with a few major drawbacks:

• You have to pick between index bloat and the use of stopwords. Stopwords are bad because they might actually be important (try searching "if let" in mdBook if you're feeling brave), but without them, you spend a lot of space on text that doesn't matter.
• Example code also tends to have a lot of irrelevant stuff in it. Like stop words, we'd have to pick potentially-confusing or bloat.

Neither of these problems are deal-breakers, but they're worth keeping in mind.

[Zalathar]

Bors hasn't noticed that this was merged.

@bors r- retry

[GuillaumeGomez]

🎉

[Zalathar]

Be aware that there were some big doc perf regressions in the rollup: #145589 (comment)

[GuillaumeGomez]

Wow indeed. I expected regressions, but not that big. The end result is worth it, but we definitely need to improve that.

[klensy]

regressed both files count https://perf.rust-lang.org/compare.html?start=b96868fa2ef174b0a5aeb3bf041b3a5b517f11f8&end=037df456409539306b50018308b8dfdc6f009d6c&stat=size%3Adoc_files_count&showRawData=true and and doc_bytes https://perf.rust-lang.org/compare.html?start=b96868fa2ef174b0a5aeb3bf041b3a5b517f11f8&end=037df456409539306b50018308b8dfdc6f009d6c&stat=size%3Adoc_bytes&showRawData=true.

For many-assoc-items files count changed dramatically 52 -> 2310, size about 30%

[Zalathar]

Seeing this merged PR at the top of the non-approved part of the queue makes me keep miscounting the number of rollup=always PRs, so let's fix that.

@bors p=0

[bjorn3]

@bors r-