[performance regression] fd slower than find? (bisected)

[desbma]

I found a case where fd is ~35% slower than find and I don't understand why.

$ hyperfine "fd 'appmanifest_.*.acf' ~/.local/share/Steam"
Benchmark 1: fd 'appmanifest_.*.acf' ~/.local/share/Steam
  Time (mean ± σ):     173.5 ms ±   1.4 ms    [User: 505.8 ms, System: 4231.7 ms]
  Range (min … max):   171.1 ms … 175.8 ms    17 runs

$ hyperfine "find ~/.local/share/Steam -name 'appmanifest_.*.acf'"
Benchmark 1: find ~/.local/share/Steam -name 'appmanifest_.*.acf'
  Time (mean ± σ):     127.9 ms ±   1.2 ms    [User: 63.7 ms, System: 63.6 ms]
  Range (min … max):   126.0 ms … 130.5 ms    23 runs

I tried passing the -g, -I, -t f, -j 1, -j 4 arguments to fd, but none of that changed the numbers significantly.

I'm on Arch Linux, and I use the official fd package.

[desbma]

It seems older versions of fd are ~200-300% faster, I am trying to bisect to the regression commit.

[desbma]

git bisect start
# bad: [a0062b9a1be36a4b1072b8e476462f71c3a1f78a] Disable invalid CWD test on Windows
git bisect bad a0062b9a1be36a4b1072b8e476462f71c3a1f78a
# good: [dd07bc9ef1f721ab6c5a1b3611b6ac19402361e2] Bump min. required Rust version to 1.36
git bisect good dd07bc9ef1f721ab6c5a1b3611b6ac19402361e2
# bad: [8da936abd8f62464da8d432cbaf4e1d78f03c52f] Merge branch 'pr/opposing-options' of https://github.com/Asha20/fd into pr/opposing-options
git bisect bad 8da936abd8f62464da8d432cbaf4e1d78f03c52f
# bad: [74c3431a2bf74ce78c26974f3cc07570e1d3baf3] improve time option usage (#645)
git bisect bad 74c3431a2bf74ce78c26974f3cc07570e1d3baf3
# good: [0b7febc3b695753db4db845f2e7b635fcfefbcbc] Windows support (if GNU ls is installed)
git bisect good 0b7febc3b695753db4db845f2e7b635fcfefbcbc
# good: [65b65b32be0cb987cf8bbed5fed9f7202deefa06] Update lockfile
git bisect good 65b65b32be0cb987cf8bbed5fed9f7202deefa06
# good: [ddee6aa8f333e4031c4bd272d31c010f7cc93fa3] Revert "Always enable colors on Windows, closes #469"
git bisect good ddee6aa8f333e4031c4bd272d31c010f7cc93fa3
# bad: [53c338d71fbe46375937921bd9acde49524cbc71] Windows: Always enable colors if --color=always is set
git bisect bad 53c338d71fbe46375937921bd9acde49524cbc71
# good: [27162c2729230ea9809f73cebba112cb229286bb] Update CHANGELOG
git bisect good 27162c2729230ea9809f73cebba112cb229286bb
# bad: [78cde856b1064ea458f6ec7dda8c66f560aac94c] Update dependencies
git bisect bad 78cde856b1064ea458f6ec7dda8c66f560aac94c
# good: [a954944d69c644a9ec2a0c10c10812ad87859916] Prepare 8.1.0 release
git bisect good a954944d69c644a9ec2a0c10c10812ad87859916
# first bad commit: [78cde856b1064ea458f6ec7dda8c66f560aac94c] Update dependencies

So the regression was caused by 78cde856b1064ea458f6ec7dda8c66f560aac94c

[tavianator]

So probably https://github.com/sharkdp/fd/issues/599

[desbma]

The actual performance difference:

hyperfine "/tmp/fd-78cde856b1064ea458f6ec7dda8c66f560aac94c 'appmanifest_.*.acf' ~/.local/share/Steam" "/tmp/fd-a954944d69c644a9ec2a0c10c10812ad87859916 'appmanifest_.*.acf' ~/.local/share/Steam"
Benchmark 1: /tmp/fd-78cde856b1064ea458f6ec7dda8c66f560aac94c 'appmanifest_.*.acf' ~/.local/share/Steam
  Time (mean ± σ):     141.9 ms ±   1.5 ms    [User: 573.3 ms, System: 3265.0 ms]
  Range (min … max):   139.2 ms … 144.6 ms    21 runs

Benchmark 2: /tmp/fd-a954944d69c644a9ec2a0c10c10812ad87859916 'appmanifest_.*.acf' ~/.local/share/Steam
  Time (mean ± σ):      52.0 ms ±   2.6 ms    [User: 1135.5 ms, System: 192.5 ms]
  Range (min … max):    48.0 ms …  60.7 ms    55 runs

Summary
  '/tmp/fd-a954944d69c644a9ec2a0c10c10812ad87859916 'appmanifest_.*.acf' ~/.local/share/Steam' ran
    2.73 ± 0.14 times faster than '/tmp/fd-78cde856b1064ea458f6ec7dda8c66f560aac94c 'appmanifest_.*.acf' ~/.local/share/Steam'

[desbma]

So probably #599

I am not sure it's related. How can I downgrade a dependency version to check? It seems Cargo.toml has outdated version constraints, and whatever I set there it is ignored and overridden by Cargo.lock:

$ cargo add [email protected]
    Updating crates.io index
      Adding ignore v0.4.14 to dependencies.
             Features:
             - simd-accel
$ cargo update
    Updating crates.io index
$ grep -A 1 ignore Cargo.lock
 "ignore",
 "jemallocator",
--
name = "ignore"
version = "0.4.18"

[tmccombs]

I'm not sure if there is a better way to do this, but you could set the version in Cargo.toml to a more specific version.

[desbma]

I tried that, this is also what cargo add does, but for some reason it is ignored.

You can easily see that Cargo.toml and Cargo.lock are desynchronized, because at the regression commit, ignore is set in Cargo.toml to version 0.4.3, but is at 0.4.15 in Cargo.lock.

[TuongNM]

Did you try setting the exact version with = 0.4.14 inside the Cargo.toml? The fact that 0.4.3 inside Cargo.toml results in 0.4.15 inside Cargo.lock is default Cargo behavior. Without any range requirements this is equivalent to ^0.4.3.

See also the Cargo book.

[desbma]

@TuongNM thanks, that was it.

So I am able to confirm that the regression is indeed mostly due to the ignore dependency, in short it's fast with version 0.4.14 and slow with 0.4.15.

[tavianator]

Looks like this is confirmed to be a duplicate of #599 then