We now have an "official" badge that you can use in your libraries or projects to indicate that it runs with babashka: https://github.com/babashka/babashka#projects Thanks to @rahul080327

observation without analysis: `bb` startup is nearly instant when run in succession, but when I open a new iTerm, it takes an extra 500ms on the first time~

aaaand I withdraw that anecdote ^ it's due to my lazy loaded powershell10k zsh profile

Another situation in which the first invocation of bb might be slower is when it fetches deps declared in bb.edn

A demo of fs/walk-file-tree , walk the tree for finding all .git dirs: https://gist.github.com/borkdude/123ad8a889e3261178054ee3867a8a3c

the Files/walkFileTree api is so bad

can't deal with it without mutation (like most visitor pattern APIs)

there's a Files/walk API that returns Stream<Path>

(but cannot short-circuit)

I came up with that example because someone complained about the performance of fs/glob compared to find, but it turned out that using find you can filter on file type and you can prevent doing the glob, which is why it's faster. If you do that manually using fs/walk-file-tree the bb example is several times faster.

how does fs/glob work?

it's implemented on top of fs/walk-file-tree which is in turn implemented on top of the java nio stuff

it uses the regular java nio glob stuff

https://github.com/babashka/fs/blob/master/src/babashka/fs.cljc

I guess we could make fs/glob take an ordinary predicate instead of a glob too, or make a variation

but so far I haven't really needed it

@ghadi Maybe iteration could deal with file tree walking? ;)

it could

or file-seq

yeah, file-seq always works... but not much you can control there

(everything we do, Rich did in 2008 🙂 )

I'm just not a fan of the APIs that require mutation in userspace code (the one that takes a https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/FileVisitor.html)

It's running already over a minute long here:

$ time bb -e '(count (filter #(= ".git" (fs/file-name %)) (file-seq (io/file "."))))'

Files/walk might be better (although streams are not directly reducible)

Yes, that example was a performance optimization over using the non-mutative fs/glob :)

This is the "recommended" approach if you don't care about performance vs find :

$ bb -e '(time (count (filter fs/directory? (fs/glob "." "**/.git" {:hidden true}))))'

In babashka.fs I didn't try to make things fancy, it's just a thin layer over java nio, generally

Doesn't Files/walk basically do what file-seq does? What's the advantage of using the former?

presumably Files/walk is more efficient

file-seq delegates to tree-seq and checks if every file is a directory

This works:

bb -e '(-> (java.nio.file.Files/walk (.toPath (io/file ".")) (into-array java.nio.file.FileVisitOption [])) (.iterator) (iterator-seq))'

clojure and babashka are pretty good at filtering

(into [] (filter git-dir?) (walk ...))

Yeah, but it's much much slower. Terminating early makes the example 4x faster, which was the original argument with someone on Twitter vs find ;)

$ time bb -e '(-> (java.nio.file.Files/walk (.toPath (io/file ".")) (into-array java.nio.file.FileVisitOption [])) (.iterator) (iterator-seq) (count))'
192654
bb -e    0.52s  user 1.74s system 48% cpu 4.699 total

$ time bb -e '(count (fs/glob "." "**" {:hidden true}))'
192653
bb -e '(count (fs/glob "." "**" {:hidden true}))'   1.24s  user 1.77s system 99% cpu 3.032 total

(the difference of 1 is because glob doesn't include the root dir)