From the Zed Blog: Why was it slow, and why is it still slow?

Zed's platform  offers insights and resources on technology, software development, and entrepreneurship. Through articles, tutorials, and personal stories, Zed shares  knowledge and practical advice for individuals looking to succeed in the tech industry. Readers can learn about startup culture, product development strategies, and career growth opportunities to navigate the complexities of the tech landscape effectively.

Zed's team improved project search performance by addressing task scheduling priorities rather than low-level optimizations. The original implementation treated all search tasks equally, causing tasks that confirm matches to be starved by the overwhelming number of candidate-checking tasks. By restructuring the code to explicitly prioritize confirming matches in files already known to contain results using select_biased!, they reduced first-match latency from 3.8 seconds to 1.1 seconds on Linux kernel searches and from 16.8 seconds to 32 milliseconds on Rust repository searches. The solution demonstrates how understanding concurrency patterns and work distribution can yield significant performance gains without resorting to SIMD or assembly-level optimizations.

Nerd-sniped: Project Search — Zed's Blog

<blockquote>
I live, breathe and squeeze performance. Each microsecond shaved is bliss. Donald Knuth? Never heard of him.
</blockquote>
Your post demonstrates why you should have listened to Donald Knuth: Optimize your algorithms, before you optimize anything else. Optimizing your low-level code first is premature optimization, for more than one reason.
First, because it is likely to change when you optimize your algorithms.
Second, what Big O notation was invented to describe: If you make checking an item run twice as fast, then your O(n) algorithm now runs in, comparatively, O(n/2) time. On the other hand, if you could switch to an O(log n) algorithm, that will likely show far greater gains unless you are dealing with a small set of items (generally &lt;=50, based on my experiences). Once your algorithms are optimized, optimizing your code could get you to, for example, O((log n)/2).
Donald Knuth did not say “Don’t do low-level optimization”. His quote is about optimizing how you optimize.