so sick

you already thought through it 😛

Just try on Linux and no regressions...it works great! 👍 1408 ms against 3435 ms 🔥

nbb runs on a JIT-ed environment which is probably the reason it works so well. Are you using nbb 0.1.6?

nbb 0.1.5 used to be 2x as slow as the old bb :)

Yep just updated both, so is it just specific examples like this loop that nbb would do better at or do you think it will be faster in all cases? trying to choose between bb and nbb for a project at the moment, its probably not going to make much of a difference but still interested 😄

Hard to say. Parsing is way slower in nbb (subject to optimization improvements) so it really depends on the workload

also startup time of nbb is slower than bb

not that it really matters probably for most utils, but it's 180ms vs 20ms or so

interesting, bb has always seemed like it had slower startup time in my tests

[email protected] ~ % time ./bb  "(prn \"hello\")"
"hello"
./bb "(prn \"hello\")"  0.11s user 0.03s system 57% cpu 0.239 total
[email protected] ~ % time nbb -e "(prn \"hello\")"
"hello"
nbb -e "(prn \"hello\")"  0.11s user 0.01s system 107% cpu 0.112 total

huh, that's weird! try to run it multiple times. the first time may be a little slower due to file system stuff.

$  time ./bb  "(prn \"hello\")"
"hello"
./bb "(prn \"hello\")"   0.01s  user 0.01s system 82% cpu 0.025 total

on my system, I get for nbb:

$ time nbb -e "(prn \"hello\")"
"hello"
nbb -e "(prn \"hello\")"   0.19s  user 0.02s system 108% cpu 0.192 total

Ah yes that would be the reason then 😄 forgot graal can’t do arm yet

looks like it could be close though, you can build a version that works on m1 yourself now https://github.com/oracle/graal/issues/2666

I think trying the arm binary in docker on m1 in a linux container should also resemble what performance you could get. But it'd be cool if you could try the real m1 version too :)

It seems bb is now as fast as python3 in loops?

import time

start = time.time()

val = 0
cnt = 10000000

while (cnt != 0):
    cnt = cnt - 1
    val = val + 1

end = time.time()

print("Took:", end - start)
print(val)

Took: 1.1271159648895264
10000000

node does it in 8ms, about the same time as jvm clojure

console.time("nbb")
var val = 0;
var ctn = 10000000;
while(ctn !== 0) {
	ctn = ctn - 1;
	val = val + 1;
}
console.timeEnd("nbb");

yeah, but this is because node is compiled and python is, like bb, interpreted.

yeah I know, just surprising node is so fast, I always thought of it as slower than the jvm

yeah, it seems v8 has really been catching up on performance

imagine if that much effort had been sunk into tools for a real language

:)

for comparison, ruby:

$ time ruby /tmp/test.rb
10000000ruby /tmp/test.rb   0.27s  user 0.02s system 98% cpu 0.288 total

With GraalVM ruby:

$ time $GRAALVM_HOME/bin/ruby /tmp/test.rb
10000000$GRAALVM_HOME/bin/ruby /tmp/test.rb   0.15s  user 0.06s system 145% cpu 0.147 total

Graal Python:

$ time $GRAALVM_HOME/bin/graalpython /tmp/test.py
Took: 0.21900010108947754
10000000
$GRAALVM_HOME/bin/graalpython /tmp/test.py   1.16s  user 0.19s system 278% cpu 0.483 total

bash 😆 (I mean it is what babashka is meant to replace )

time ./loop.sh
./loop.sh  42.95s user 2.40s system 99% cpu 45.354 total

:-D

Btw in the browser (chrome) I get about the same time as with bb: https://babashka.org/xterm-sci/

Safari seems to be faster!

user=> (time (loop [val 0 cnt 10000000] (if (pos? cnt) (recur (inc val) (dec cnt)) val)))
"Elapsed time: 735.000000 msecs"
10000000

sort of like set -x I believe

@U08BJGV6E babashka does have a --debug setting but the output is purely for debugging, not for daily usage. I think we could have a babashka.tasks global switch for this, like :command-print-fn or so in which you can do your own thing and also provide a default

for now you could also make your own shell and clojure wrapper

which just prints the args first and then calls the original

Makes sense, thank you. It would be a welcome feature for sure. Again, mostly for debugging:

; bb --debug run test

 ;; deps

(ns user-4b3db898-5cee-4604-8d36-839d2be6f97d )
(require '[babashka.tasks])
(when-not (resolve 'clojure)
  ;; we don't use refer so users can override this
  (intern *ns* 'clojure babashka.tasks/clojure))

(when-not (resolve 'shell)
  (intern *ns* 'shell babashka.tasks/shell))

(when-not (resolve 'current-task)
  (intern *ns* 'current-task babashka.tasks/current-task))

(when-not (resolve 'run)
  (intern *ns* 'run babashka.tasks/run))

nil
(def test (binding [
  babashka.tasks/*task* '{:name test, :doc "Run project tests via Kaocha. Args will be forwarded to Kaocha.", :task (apply shell "bin/kaocha" *command-line-args*)}]
  nil
(apply shell "bin/kaocha" *command-line-args*))) test


Loading namespaces:  (e

This prints (apply shell "bin/kaocha" *command-line-args*) which is what I'm invoking but what I'm interested in is whether I managed to invoke bin/kaocha as I had intended

yeah make sense. What about doing this in :init:

:init (do (defn shell [& args] (println (str/join " " args)) (apply babashks.tasks/shell args))

Yep, that should work for now although it still only tells me what args are being passed to shell and not whether that results in the process invocation I intended to do. I.e. it won't tell me if I'm misusing the shell api

I'm not sure if I get that. What else other than the above would you expect a built-in function to do?

I looked at examples https://book.babashka.org/#parallel and https://book.babashka.org/#tasks:clojure and I see that multiple args to the cli are sometimes given in one string and other times one arg per string. And I wasn't sure how quoting etc would work

right. the first argument to those functions are parsed with process/tokenize

which works similar to how shell strings work: foo bar becomes ["foo" "bar"] but 'foo bar' becomes ["foo bar"]`, etc

so (into (process/tokenize (first args)) (rest args)) should be the accurate representation

but for printing you need not worry about this probably

but for usability I think it'd be nice to have an optional function which gets to see the arguments before invocation

I"ll make an issue

https://github.com/babashka/babashka/issues/1178

Thank you. Yeah, really not a strong point from my end, just that it's probably more accurate if done closer to actual invocation

agreed

oh I think there's already a hook that you could abuse :)

$ bb -e '(babashka.process/process ["ls" "-la"] {:escape (fn [arg] (prn arg) arg)})'
"ls"
"-la"

This :escape hook is really there for Windows which has some odd corner cases with process arguments and defaults to some sane behavior. It's applied to every argument

but I guess we want to have something similar for all arguments

My tasks would all return an :anomaly object if they fail I guess I wrap everthing with a check

You can control failure with :continue true which will never throw but you will have to handle the result yourself

I'll check

The best way to do this currently is probably to move your code to a file and then do load-pod + require in that file.

and then require that file in the tasks

:thumbsup:

works good

@U012RPAAR0E It hasn't

Ah ok

Are you asking for usage within bb or with fs on the JVM?

within bb, I'm trying to see how to watch for file changes

Preferably with something like inotify

We have two file watcher for bb, one written in Rust and one written in Go: https://github.com/babashka/pod-registry Both should work fine.

Oh excellent! Thank you

I have an example here where I watch sources from the babashka book and rebuild on change, and then refresh a browser to show the new renderings https://github.com/babashka/book/blob/master/script/watch.clj

Not yet, this is on the TODO list

Maybe you could try writing it in #nbb too? that can load arbitrary js dependencies 😄

That's what I was going to say too :)

Thanks