This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-01-14
Channels
- # adventofcode (2)
- # announcements (61)
- # babashka (26)
- # beginners (125)
- # calva (63)
- # cider (33)
- # clj-kondo (40)
- # cljs-dev (24)
- # clojure (165)
- # clojure-australia (8)
- # clojure-dev (4)
- # clojure-europe (44)
- # clojure-finland (1)
- # clojure-greece (4)
- # clojure-losangeles (1)
- # clojure-nl (28)
- # clojure-taiwan (3)
- # clojure-uk (64)
- # clojurescript (2)
- # core-async (14)
- # datomic (34)
- # docker (2)
- # fulcro (9)
- # garden (1)
- # jobs (4)
- # jobs-discuss (21)
- # kaocha (3)
- # off-topic (48)
- # pathom (4)
- # practicalli (3)
- # remote-jobs (3)
- # shadow-cljs (46)
- # spacemacs (6)
- # sql (4)
- # tools-deps (22)
- # xtdb (5)
- # yada (2)
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)
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
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
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.or does it "cache" files that you have recently changed into a faster part of the OS?
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
so if my laptop battery would go dead, chances are it wouldn't have been written to disk yet, on save?