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

Faster type-driven search

This is the most noticeable problem, when I test it. Type-driven search feels slow, because it has to buffer all of the results before it can show any of them. We don't have a fancy trick algorithm like the backlog heap in prefix search, and we should,

To fix this, we might need to ditch pure bitmaps in favor of some other IR data structure to store the inverted index. It's better now than it used to be, at least in terms of memory management, but we need a better incremental search algo here.

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.

[GuillaumeGomez]

I didn't look at the code yet, just testing the output. As I already said, I love the new GUI, so big 👍 from me on it.

I noted a few things while testing the new output (not blockers, but definitely improvements for potential future PRs):

• A visual indicator that more results are loading would be great.
• The ( ) empty parens on the tabs titles feel a bit weird. I would simply not display the number until we're done searching or eventually to add another visual indicator that it's not done yet (a rotating spinner?).
• The cog gear for the setting menu got updated, a reason for that?

Now for the feeling about the search itself: it is MUCH better. No more blocking UI or anything, just working. It's definitely great.

[GuillaumeGomez]

For the review, another thing that's not great is that UI and search index are the same commit (the first one). Not sure if intended or not, but it makes the review quite awful to go through. ^^'

[GuillaumeGomez]

Not needed, in js, if variable and field have the same name, you can just write the variable name and it'll create a key with the variable name, taking the variable value.

[notriddle]

Good catch.

[GuillaumeGomez]

I went through the code and didn't see anything standing out but I feel like I missed most of it and definitely can't picture the whole thing.

I think the PR is fine, minus the various comments I made, tests are there to enforce it and the demo works super nicely.

[notriddle]

Trying to address some of the questions asked in the review:

A visual indicator that more results are loading would be great.

I agree. The empty parens was too subtle. I'll try to get a better indicator drawn up within about a week.

The cog gear for the setting menu got updated, a reason for that?

I want all four icons to have roughly equal visual weight. In the old toolbar, the cog looked darker than everything else. It's very noticeable when you blur it.

It's particularly galling, because that Settings button is not the most important icon in the toolbar, so it should not be the most prominent.

[GuillaumeGomez]

Makes sense. 👍

Please ping me once the changes have been done for next review round.

[notriddle]

output.mp4