4 ms·

How so? You can easily extend the searchFn to do the glob matching of files for you. I wanted to keep it dependency free. So I fail to see how fdir has "absolut

How so? You can easily extend the searchFn to do the glob matching of files for you. I wanted to keep it dependency free. So I fail to see how fdir has "absolutely nothing to do with globbing"? Care to explain?

lhorie 7y ago
Not parent, but I think their argument is that this lib doesn't implement a glob interface so calling it a glob alternative is misleading, i.e. one cannot easily replace a globbing library with this if they expose the glob DSL as an interface. It's more accurate to say that your lib is a recursive-readdir alternative.
- thecodrr 7y ago
  In that case, fair enough. But no reason to be dishearted, we can always make "fdir-glob" that has globbing built in :D but you are right, not an easy* alternative but still an alternative.
tastroder 7y ago
Would you mind changing the submission title? Your library simply does not glob (that's a word with fixed meaning), which is likely a rather expensive part of the hot path for real use cases. Aside: Looking at the hyperfine results below, have you benchmarked this JS optimization vs. implementing it in C++ instead and consuming the results of that?
- thecodrr 7y ago
  Hey, thanks for the interest. No, I cannot change the title because I don't have editing capabilities anymore. I don't see the point of implementing it in c++ simply because I wanted to keep it simple, dependency free and easy to maintain. The fact that I know very little C++ also influenced that decision. Moreover, I am sure that way would be faster (from my understanding).
  - tastroder 7y ago
    The upside would be that you can specifically control when to pass values between the underlying C++ and the v8 runtime. But anyway, this implementation is quite nice. I tried to recreate a more meaningful benchmark between a few of the libraries you compared with but on a real file system structure rrdir and node-walk just noped out by exceeding the maximum call stack size. Increasing that yielded pretty much the same results as your library for rrfind in the sync setting with the overhead likely being down to that one returning an object (mean difference between 50-100ms higher on ~1.1 million files).
    - thecodrr 7y ago
      You give a very valid reason to tryout an implementation in C++. I will definitely look into it. Thanks. Would love to see the benchmark results! Do share a link if you can. Thanks for auditing and taking the interest!

lhorie 7y ago

Not parent, but I think their argument is that this lib doesn't implement a glob interface so calling it a glob alternative is misleading, i.e. one cannot easily replace a globbing library with this if they expose the glob DSL as an interface. It's more accurate to say that your lib is a recursive-readdir alternative.

thecodrr 7y ago
In that case, fair enough. But no reason to be dishearted, we can always make "fdir-glob" that has globbing built in :D but you are right, not an easy* alternative but still an alternative.

tastroder 7y ago

Would you mind changing the submission title? Your library simply does not glob (that's a word with fixed meaning), which is likely a rather expensive part of the hot path for real use cases. Aside: Looking at the hyperfine results below, have you benchmarked this JS optimization vs. implementing it in C++ instead and consuming the results of that?

thecodrr 7y ago
Hey, thanks for the interest. No, I cannot change the title because I don't have editing capabilities anymore. I don't see the point of implementing it in c++ simply because I wanted to keep it simple, dependency free and easy to maintain. The fact that I know very little C++ also influenced that decision. Moreover, I am sure that way would be faster (from my understanding).
- tastroder 7y ago
  The upside would be that you can specifically control when to pass values between the underlying C++ and the v8 runtime. But anyway, this implementation is quite nice. I tried to recreate a more meaningful benchmark between a few of the libraries you compared with but on a real file system structure rrdir and node-walk just noped out by exceeding the maximum call stack size. Increasing that yielded pretty much the same results as your library for rrfind in the sync setting with the overhead likely being down to that one returning an object (mean difference between 50-100ms higher on ~1.1 million files).
  - thecodrr 7y ago
    You give a very valid reason to tryout an implementation in C++. I will definitely look into it. Thanks. Would love to see the benchmark results! Do share a link if you can. Thanks for auditing and taking the interest!