You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Nexus we discovered that fs-jetpack's find was very slow. When we investigated why, it turned out to be because ignores were only being executed as an in-memory filter, not actually changing how the disk was traversed (IO). This had huge consequences (toward a full 1000ms of latency on project boot).
Maybe there are some downsides I haven't thought of but right now I'm pretty sure that it would be great for fs-jetpack to change its find engine to it.
The text was updated successfully, but these errors were encountered:
The use case is that you have a big directory nested somewhere inside the directory that the find was performed on, and you don't want to touch that big directory? Or is this something more nuanced?
On Nexus we discovered that
fs-jetpack
'sfind
was very slow. When we investigated why, it turned out to be because ignores were only being executed as an in-memory filter, not actually changing how the disk was traversed (IO). This had huge consequences (toward a full 1000ms of latency on project boot).We solved our problems by switching to
fast-glob
.The key for us was https://github.com/mrmlnc/fast-glob#how-to-exclude-directory-from-reading.
Given filters are actually affecting the IO.
Maybe there are some downsides I haven't thought of but right now I'm pretty sure that it would be great for
fs-jetpack
to change itsfind
engine to it.The text was updated successfully, but these errors were encountered: