Fork me on GitHub
#babashka
<
2021-01-14
>
jeroenvandijk08:01:08

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?

jeroenvandijk08:01:11

(it’s 25 vs 60 ms, so 30 ms difference on my machine for a hello world program)

borkdude08:01:35

Maybe file cache? Babashka itself isn’t caching anything

🙏 1
jeroenvandijk08:01:57

ah yeah true, many possibilities

jeroenvandijk08:01:40

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

borkdude08:01:11

@jeroenvandijk for benchmarking I usually use multitime

borkdude08:01:33

and/or time inside a bb program so you account for the graal startup time

jeroenvandijk09:01:24

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

borkdude09:01:37

@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 ;)

borkdude09:01:49

Bb starts way faster on linux too btw, because of dynamic linking on macOS being slow

jeroenvandijk10:01:25

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

jumar19:01:30

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)

borkdude20:01:17

@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.

jumar10:01:38

"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
Do you know about any resources that mention how OS cache affects startup time of (java) programs? I'd happy to learn more about this stuff.

borkdude10:01:05

@jumar isn't the idea of a cache that it invalidates on a change?

borkdude10:01:40

or does it "cache" files that you have recently changed into a faster part of the OS?

borkdude10:01:46

so the next change will be faster?

jumar10:01:52

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

jumar10:01:04

It caches files in RAM

borkdude10:01:32

but also for writes?

borkdude10:01:08

so if my laptop battery would go dead, chances are it wouldn't have been written to disk yet, on save?

jumar10:01:27

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)

jumar10:01:36

Yeah, that's possible

borkdude10:01:53

ok, thanks, TIL

jumar10:01:52

It's so called "write-back" cache

lread23:01:45

Writing all my project scripts in babashka gives me a satisfying GitHub stat of:

babashka 8
clojure-spin 6
☝️ 1
rich2 2