This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-01-10
Channels
- # announcements (4)
- # babashka (40)
- # beginners (39)
- # calva (16)
- # cljdoc (1)
- # cljs-dev (8)
- # clojure (72)
- # clojure-europe (10)
- # clojure-losangeles (1)
- # clojure-nl (4)
- # clojure-spec (9)
- # clojure-uk (12)
- # clojurescript (16)
- # community-development (15)
- # conjure (5)
- # cursive (5)
- # datomic (26)
- # eastwood (1)
- # emacs (7)
- # events (1)
- # figwheel-main (15)
- # fulcro (27)
- # graphql (7)
- # gratitude (4)
- # introduce-yourself (1)
- # malli (4)
- # meander (4)
- # off-topic (2)
- # other-languages (13)
- # polylith (7)
- # reagent (5)
- # reitit (5)
- # shadow-cljs (27)
- # spacemacs (4)
- # sql (3)
- # tools-deps (6)
- # xtdb (13)
"for the JVM but in babashka it will be slower :/" What's the reason string builders are slower on babashka?
Because interop is interpreted (and currently not very optimized), such optimization tricks take more time to run than going through the (precompiled!) core functions.
Similar to what happened in your Ring codec PR here: https://github.com/babashka/babashka/issues/1091#issuecomment-986643431
but this can be mitigated by using reader conditionals and just using the core funs in babashka
I still doubt it would be as fast as using the core functions, but it would be much better
What happens is that on each interop call there is reflection but the MethodHandle could be cached
also in analysis the methodhandle could already be looked up if there are enough type hints
but this is a trade-off of startup time and runtime because when not using certain functions, it will be more expensive to do this during analysis
I thought you could even prepare a bunch of hinted functions and replace them at analysis time if you have enough info
do you mean, have a #(.append ^StringBuilder x ^String y)
function and then replace?
A few hundred. https://github.com/babashka/babashka/blob/master/src/babashka/impl/classes.clj
Could pre-generate a "index" of all methods, if the instance method name is unique, we already know what to call without even knowing the arg types
A related issue:
https://github.com/babashka/babashka/pull/1138#issuecomment-1010991962
These kinds of fast-assoc
optimizations will just make things slower (or in this case not working because that method isn't exposed). So in this case it's better to introduce a :bb
reader conditional which does not use the JVM-optimized version.
What's an ideomatic way to turn a seq back into string lines, for piping into a command?
seq 10 | bb -e '(->> (line-seq (io/reader *in*)) (drop 2) (drop-last 2))'
("3" "4" "5" "6" "7" "8")
# how can I make it print
3
4
5
# ... ?
you can also replace (line-seq ...)
with *input*
and then use bb -io (->> *input* (drop 2) (drop-last 2))
seq 10 | bb -io '(->> *input* (drop 2) (drop-last 2))'
3
4
5
6
7
8
Wow - that's actually more compact than I can think of in Bash, AWK, or other Unix tools. Nice.seq 10 | head -n-2 | tail -n+3
3
4
5
6
7
8
This is more succinct in Unix tools terms. However, I ignore how well it performs on big samples.I guess head
and tail
shorter in character count.
Still -- I didn't know you could run head and tail in "inverse" (`-n -2`), whereas I was already familiar with drop
and drop-last
.
Another Babashka pro is simple filtering in the middle of the pipe:
seq 10 | bb -io '(->> *input* (drop 2) (remove #{"4" "7"}) (drop-last 2))'
3
5
6
8