Hacker News Reader

Comment by iruoy | Hacker News Reader

I just did a little test. fd seems to be about 3 times as fast.

  Command      | Mean [ms]     | Min…Max [ms]
  -------------|---------------|---------------
  `fd .conf /` | 525.6 ± 17.7  | 505.3…552.0
  `ff .conf /` | 1760.8 ± 10.2 | 1744.6…1775.3

View on HN

Looking at the code, I believe because fd uses a loop, and ff uses function recursion to walk the path tree. Function recursion is easier to write, but definitely has some overhead.

My experience is that if you have to maintain your own stack (which you'd need to in order to recursively walk directories) its faster to use the builtin stack than to implement your own.

Further, it seems that this would IO-bound not CPU-bound so whatever small overhead exists in recursion vs iteration will not be noticeable.

I think the difference is rather that `fd` uses threads and `ff` does not.

> `fd` uses threads and `ff` does not.

Author here. This is true. ff does not use threads right now. I have started learning Rust just a few days ago. I am not quite yet familiar with advanced topics such as achieving parallelism using threads in Rust and other similar stuff. My knowledge of Rust is limited at this moment and I struggled to get the language concepts to work such as ownership, lifetimes, etc. I am sure that I will be able to improvise the ff's performance by some extent by gaining some more knowledge of Rust.

UPDATE: Now ff also uses threads to achieve parallelism.

Author here. Slow behavior while searching through a large number of files is a known issue at this moment. I will definitely try to reduce it by some extent by immediately streaming to STDOUT (or to a non-TTY device if TTY is not STDOUT). Right now, the results are accumulated, filtered and then printed in one go.

Reply on news.ycombinator.com