Fork me on GitHub
#babashka
<
2020-02-14
>
jeroenvandijk09:02:25

Random shower thought... Would it be a big performance hit if Sci would support I18n? E.g. meaning error messages in other languages?

jeroenvandijk09:02:59

Sci could make Clojure more accessible to non-programmers, what if it could make programming more accessible to non-English speakers... 😎 Just saying

borkdude09:02:33

I have a branch where I promote all clojure.core vars to "real" sci vars and it just copies the metadata from the clojure vars:

$ ./bb '(clojure.repl/doc inc)'
"Returns a number one greater than num. Does not auto-promote\n  longs, will throw on overflow. See also: inc'"
I wonder if this will be noticeable in performance hit. Feel free to test; the branch is copy-vars.

borkdude09:02:26

also: it adds about 180kb to the minified sci js

jeroenvandijk09:02:54

Cool, sounds like it is an option when needed

jeroenvandijk09:02:26

Maybe at some point you want to have a sci-min and sci-full or something to support different use cases

borkdude09:02:38

but it's also nice to have when you expect resolve always to return a var. right now it can just return a function in sci, when there is no var in between

jeroenvandijk09:02:36

Yeah makes sense to have it in that use case. But let's say you want to use Sci on a website, you wouldn't want to add unnecessary data I think. Sci could have a small core and have some addons?

borkdude09:02:41

The binary size of bb isn't affected that much, so I guess it's ok in the regard. It does take a small perf hit for tight loops: https://github.com/borkdude/sci/issues/263#issuecomment-586166717

borkdude09:02:52

yeah, it's the same with excluding functions you don't want. e.g. if you don't want clojure.string, etc.

borkdude09:02:16

that's the hard part of an interpreter: you don't know what people are going to do with it, so you have to include everything

jeroenvandijk09:02:55

Yeah i understand, np. There is also always the options to let people make custom compilations (like i'm doing for my Lambda code)

jeroenvandijk09:02:27

That way you give a full experience and if others want to optimize to their use case they can (with a little work)

borkdude09:02:52

right. I guess you can also fork sci and make some tweaks, and then optimize it for your use case

borkdude09:02:29

although it would be nicer if sci offered that option. in the case of minified js on npm that's not doable, you have to get everything in there

borkdude09:02:39

because it's already compiled

borkdude09:02:05

maybe 180kb is not that big a deal?

jeroenvandijk09:02:18

for my current use case it isn't

jeroenvandijk09:02:33

I think it's ok until someone can convince you 🙂

borkdude09:02:58

yeah, maybe I shouldn't worry too much about other people's problems until they tell me 😉

jeroenvandijk09:02:34

One thing I don't know how to fix yet, which would be nice i think, is how I can make two sci packages work together

jeroenvandijk10:02:14

so if you have the normal sci package and you have another one. They cannot really work together because clojure datastructures are not minified in the same way

jeroenvandijk10:02:11

so sci might encode a map {:a 1} like {g: "a", k: whatever} and the other lib does it different like {f: "a", k: whatever}`

jeroenvandijk10:02:38

If we can solve that problem, you can abuse npm for sci libraries 🙂

borkdude10:02:25

what is the other lib?

jeroenvandijk10:02:45

in this case it was my AWS library. But now i compile it together with my custom sci to make it work

jeroenvandijk10:02:18

That's ok, but it would be more powerful if you can have arbitrary combination of libs

borkdude10:02:32

I guess that's the way to go then. I don't think I can work around advanced compiled code

jeroenvandijk10:02:46

I think we can, but i'll leave it for later 🙂

jeroenvandijk10:02:00

I'm thinking if mori.js can do it, we can do it

borkdude10:02:09

The nice thing about reified core vars is that you can also do stuff like:

$ ./bb "(ns-name (:ns (meta #'clojure.string/join)))"
clojure.string

borkdude10:02:54

I think in practice reified core vars won't be noticable in performance, only in tight loops, and that kinda sucks anyway in an interpreter 😛

borkdude10:02:16

it went from 1.5s to 2s for 1m iterations (2s is the same as joker)

borkdude10:02:29

test:

./bb -e "
(time (require '[spartan.spec :as s]))
(time (s/explain (s/cat :i int? :s string?) [1 :foo]))
(time (s/conform (s/cat :i int? :s string?) [1 \"foo\"]))
"
bb before:
$ script/lib_tests/spartan_spec_test
"Elapsed time: 58.360306 msecs"
:foo - failed:  in: [1] at: [:s]
"Elapsed time: 3.873929 msecs"
"Elapsed time: 0.783616 msecs"
{:i 1, :s "foo"}
bb with reified core vars:
$ script/lib_tests/spartan_spec_test
"Elapsed time: 60.589979 msecs"
:foo - failed:  in: [1] at: [:s]
"Elapsed time: 3.936975 msecs"
"Elapsed time: 0.642132 msecs"
{:i 1, :s "foo"}

borkdude10:02:01

(there are binaries for this in #babashka_circleci_builds )

jeroenvandijk10:02:32

Like the binary size log, are you also keeping a performance log somewhere?

borkdude10:02:11

😜

$ bb "(alter-var-root #'clojure.core/inc (constantly dec)) (inc 2)"
1

borkdude10:02:34

@jeroenvandijk When there are changes that are likely to make an impact on performance, I do measure it

👌 1
borkdude10:02:47

But not documented

borkdude22:02:59

back to the original performance while still having reified vars (implemented something like direct linking)

👍 1