Skip to content

Conversation

@Kobzol
Copy link
Member

@Kobzol Kobzol commented Oct 23, 2025

Alternative to #144.

This reduces the duration to glob **/*.rs in a rustc checkout on my PC from ~1000ms to ~820ms:

Benchmark 1: ./local
  Time (mean ± σ):     822.0 ms ±  11.2 ms    [User: 272.5 ms, System: 549.2 ms]
  Range (min … max):   811.8 ms … 849.6 ms    10 runs
 
Benchmark 2: ./upstream
  Time (mean ± σ):      1.019 s ±  0.006 s    [User: 0.468 s, System: 0.551 s]
  Range (min … max):    1.005 s …  1.026 s    10 runs
 
Summary
  ./local ran
    1.24 ± 0.02 times faster than ./upstream

@Kobzol Kobzol requested a review from tgross35 October 23, 2025 07:14
Comment on lines +951 to +952
// filename from `DirEntry` here, we store it proactively (we still
// have to heap allocate it).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"still"? afaict this adds an allocation. So it's surprising that allocating an extra OsString is still cheaper than getting the filename from the path later.

If you keep the whole DirEntry you could call file_name_ref on cfg(unix) to avoid that allocation too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a bit surprising, but the benchmark is quite clear on the results. It's one allocation vs potentially tens/hundreds/thousands of iterations of components, which seemingly isn't cheap, perf.-wise.

file_name_ref is unstable, as far as I can see?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

file_name_ref is unstable, as far as I can see?

Right, too bad.

Regarding the overhead, maybe wait until my rust PR lands and then benchmark again? The file_name optimization looks like it just might give us that 20% speedup too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough, once it gets into nightly, I'll benchmark it against a previous nightly to see if there's a big difference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants