Clojurians Log v2
babashka
I’m observing something interesting, maybe you already know though. When I run a babashka script I noticed that subsequent runs are faster. When I make some whitespace changes this first time slowness comes back. As if something is caching something. Could it be graalvm underlying Babashka?
(it’s 25 vs 60 ms, so 30 ms difference on my machine for a hello world program)
Maybe file cache? Babashka itself isn’t caching anything
1🙏ah yeah true, many possibilities
I was benchmarking my program manually on startup time and then i noticed this. If you are not careful you think it’s the program that is faster and not this caching
@jeroenvandijk for benchmarking I usually use multitime
and/or time inside a bb program so you account for the graal startup time
Yeah that makes sense. It caught me by surprise. Hadn’t consciously thought about filesystem caching though, but that explains a few patterns. E.g. the first time you run a graalvm image is also a lot slower than subsequent times. Good to be aware of this
@jeroenvandijk if you are on macOS: macOS also has some checks for binaries and they do an http request to verify if this binary is allowed to run, the first time. I would be surprised if this affects bb scripts as well, but maybe if you are running them using a shebang? Turning internet off should help ;)
Bb starts way faster on linux too btw, because of dynamic linking on macOS being slow
I didn’t test with shebang yet. This was all via bb myscripthere.clj . So i like to believe in your hypothesis about the file cache
Without knowing specifics about Bb and file cache Id be very surprised if a whitespace change invalidated OS page cache (or rather made it slower)
@jumar Not that I know anything about this, but why would a space not invalidate a page cache? Is the OS cache this clever that it checks on non-significant whitespace changes? Now that would surprise me.
"Invalidate" was a bad term. The purpose of the OS page/file cache is to speed up potentially slow IO operations so instead of a few hundres MB/s you can achieve several GB/s or more - every read and write goes through the cache. Just because you write a new whitespace to the while shouldn't make it any slower. Now, many editors actually copy the file (create a new inode) so I was wondering how that affects caching - a quick experiment suggests that both files have similar portions cached in the RAM (`RES`):
dd if=/dev/zero of=file.txt count=1024 bs=1048576
fincore file.txt
RES PAGES SIZE FILE
700.8M 179393 1G file.txt
cp file.txt file2.txt
fincore file2.txt
RES PAGES SIZE FILE
688.6M 176282 1G file2.txt@jumar isn't the idea of a cache that it invalidates on a change?
or does it "cache" files that you have recently changed into a faster part of the OS?
so the next change will be faster?
I said that "invalidates" was a bad term 🙂. It doesn't matter - your changes will be written to the underlying storage at one point and it shouldn't affect speed much - especially if it's such a simple change
It caches files in RAM
but also for writes?
so if my laptop battery would go dead, chances are it wouldn't have been written to disk yet, on save?
Yes, it's even more important for writes - reads may (initially) go to the underlying storage but writes always go to the cache first (unless you use direct/raw io)
Yeah, that's possible
ok, thanks, TIL
It's so called "write-back" cache
Writing all my project scripts in babashka gives me a satisfying GitHub stat of:
861☝️2