folder/readdir

Recursively read a directory, blazing fast. Use with picomatch or micromatch to match globs.

readdir's Issues

EPERM: operation not permitted,

Hi,

Running on average windows disk I run in to problems that sometimes access is not allowed or something like that. I am fine with this but I do want the crawl to continue and just log the errors. I couldn't find any solution on how to do this.

UnhandledPromiseRejectionWarning: Error: EPERM: operation not permitted, scandir 'c:\Config.Msi'

I can ofcourse catch this but then still the crawl stops.

showing dot files by default

readdir/lib/async.js

Line 64 in 4198053

if (options.dot === false && file.name.startsWith('.')) return;

should this be || as opposed to && or something else? (in lib/sync as well)

after looking a little further, methinks the previous logic works due to options.dot never being initialized anywhere

if (options.dot !== true && file.name.startsWith('.')) return

btw, this is absolutely awesome!!!!!!!!!!!!!!!!!!!!!!

Great work here! But your benchmark results are different for my setup

Here are the results I am getting on my system.

First run:

# recursive ~51336 files
             fdir x 651 ops/sec (3,259 runs sampled)
  @folder/readdir x 421 ops/sec (2,106 runs sampled)
 readdir-enhanced x 72 ops/sec (362 runs sampled)
         readdirp x 59 ops/sec (299 runs sampled)
# recursive ~220 files
             fdir x 3,374 ops/sec (16,872 runs sampled)
  @folder/readdir x 2,778 ops/sec (13,891 runs sampled)
 readdir-enhanced x 501 ops/sec (2,508 runs sampled)
         readdirp x 433 ops/sec (2,166 runs sampled)
# single directory (~5-10 files)
             fdir x 39,164 ops/sec (195,824 runs sampled)
  @folder/readdir x 37,425 ops/sec (187,128 runs sampled)
 readdir-enhanced x 28,414 ops/sec (142,073 runs sampled)
         readdirp x 4,410 ops/sec (22,053 runs sampled)

Second run:

# recursive ~1550 files
             fdir x 591 ops/sec (2,957 runs sampled)
  @folder/readdir x 453 ops/sec (2,267 runs sampled)
 readdir-enhanced x 65 ops/sec (328 runs sampled)
         readdirp x 59 ops/sec (296 runs sampled)
# recursive ~220 files
             fdir x 3,173 ops/sec (15,869 runs sampled)
  @folder/readdir x 2,730 ops/sec (13,651 runs sampled)
 readdir-enhanced x 461 ops/sec (2,307 runs sampled)
         readdirp x 426 ops/sec (2,130 runs sampled)
# single directory (~5-10 files)
             fdir x 36,963 ops/sec (184,815 runs sampled)
  @folder/readdir x 37,717 ops/sec (188,586 runs sampled)
 readdir-enhanced x 24,393 ops/sec (121,966 runs sampled)
         readdirp x 4,368 ops/sec (21,843 runs sampled)

You have done some epic work here with your library but creating your own benchmarking library (as tempting as it may be) is probably not the best way to measure performance. Why not use benchmark.js or benny (benny uses benchmark.js) that fdir uses?

Supposing that you made no error (which is very improbable in software) with your benchmark library, the results posted in your README are still not accurate. The only area where @folder/readdir has an edge on fdir is single directory crawling and that too only on some runs.

In any case, you have done amazing work here! Kudos!

---

My system specs are:

OS: Kubuntu 20.10 x86_64 
Host: GS63VR 7RF REV:1.0 
Kernel: 5.4.111-0504111-generic 
Shell: bash 5.0.17 
DE: Plasma 5.19.5 
WM: KWin 
Terminal: konsole 
CPU: Intel i7-7700HQ (8) @ 3.800GHz 
GPU: NVIDIA GeForce GTX 1060 Mobile 
GPU: Intel HD Graphics 630 
Memory: 6012MiB / 15896MiB