4 ms·

I just did a little test. fd seems to be about 3 times as fast. Command | Mean [ms] | Min…Max [ms] -------------|---------------|---------------

by iruoy 8y ago

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

Someone1234 8y ago
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.
- winstonewert 8y ago
  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.
  - vishaltelangre 8y ago
    > `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.
    - vishaltelangre 8y ago
      UPDATE: Now ff also uses threads to achieve parallelism.
vishaltelangre 8y ago
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.

by iruoy 8y ago

Someone1234 8y ago

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.

winstonewert 8y ago
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.
- vishaltelangre 8y ago
  > `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.
  - vishaltelangre 8y ago
    UPDATE: Now ff also uses threads to achieve parallelism.

vishaltelangre 8y ago

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.