see other blogs

What the Rust Search benchmarks actually measure

Parth Jadhav2 min read
RustPerformanceOpen Source

Rust Search is my file-search library for Rust applications. Its README contains a frequently repeated figure: a 17.25× difference compared with Glob. The number is much more useful when it travels with the conditions of the measurement.

This article explains the published benchmark results. It does not report a new benchmark run.

Two comparisons, two datasets

The published README describes an M2 MacBook Air with 16 GB of unified memory and measurements made with Hyperfine.

The Glob comparison uses a directory containing roughly 300,000 files:

ImplementationPublished mean time
rust_search1.317 seconds
Glob22.728 seconds

Dividing those means gives the reported relative difference of about 17.25. It describes that workload on that machine. It is not a universal multiplier for every directory, query, filesystem, or library version.

The fd comparison uses a different directory, containing roughly 45,000 files:

ImplementationPublished mean time
rust_search680.5 milliseconds
fd -e .js738.7 milliseconds

That comparison reports a much smaller difference, about 1.09×. Do not compare the absolute times across the two tables as though they measured the same dataset. The README explicitly notes that fd and Glob are different tools with different use cases.

Match the work before timing it

A useful comparison needs equivalent work. Check the search roots, filename matching, extensions, hidden-file behavior, ignore rules, depth, and result limits. A faster result that omits files is not equivalent to a slower complete result.

Directory contents matter too. File counts alone do not describe the depth of a tree, storage latency, metadata costs, or the distribution of matches. Running a benchmark repeatedly can also warm filesystem caches. Record those conditions rather than treating them as invisible details.

Before timing two implementations, compare their result sets. Decide whether ordering matters. If one implementation sorts matches and another does not, include or exclude that work consistently.

Use the library in its actual context

Rust Search exposes a builder API for configuring a query:

use rust_search::SearchBuilder;
 
let files: Vec<String> = SearchBuilder::default()
    .location("./src")
    .ext("rs")
    .build()
    .collect();

The versioned API documentation describes the available options. Check the version installed in your application before adopting examples from the current source repository.

The project page links to the crate, source, and documentation. For a real application, measure representative queries in the environment where they will run. Keep the historical benchmark as context, then make the decision using your own workload.

All thoughts are mine, refined by AI