Clojurians Log v2

Hi Daniel!

@spieden As you may have noticed portkey is very very young. We share the goal of “transparent local dev -> serverless deployment”

i’d been holding back on figuring out much of what you guys have well in progress

startup latency: we haven’t worked on it so it’s the usual sluggish startup

for my use case it really doesn’t matter, as step functions state machines are long running

i’ll try to get some experimenting in soon =)

we have a tree-shaker, for now it doesn’t cover clojure.jar, but with time, love and care it could be robust enough to remove unneeded stuff from clojure and yields fastest startups

if you wat to experiment you’ll have to dig in the code to use deploy! rather than mount (which has api gateway stuff)

ok cool

so the tree shaking only covers the clojure code i’m guessing — are all bytecode jars on the classpath included?

basically kryo and clojure are left untouched (plus a couple of classes and namespaces), everything else is shaken

@viesti loves to tree-shake hadoop parts

Currently the tree-shaker has a bug on genclassed classes

hadn’t encountered kryo before. only JVM slimming i have previous experience with is a little ProGuard

so have been tossing at @cgrand this puzzle of a parquet->avro conversion which shrinks from 90MB jar to 5MB, but as said, there are some things to cover still :)

loading resources/classes based on runtime information is the basic dilemma, more actual use of portkey would help to see what is most important to cover

hmm yeah

so code’s being run out of these kryo files vs .class files?

Compared to ProGuard which shake classes, we shake an object graph rooted at the closure we want to deploy to Lambda

so we have to send two things: classes and actual instances

hmm, your portkey.core/as-doto* is very similar to our bean-dip lib except w/ reflection =) https://github.com/uwcpdx/bean-dip/

oh i see

yeah vars are objects

so kryo is used to serialize instances

starting from a live graph of objects gives us an edge over ProGuard (especially when it comes to clojure code) as we have more information

spieden: it’s only called during macroexpansion and that’s true than we could certainly get away without reflection at all

ah i see. i didn’t think of that approach for some reason — just went purely on naming convention and let *warn-on-reflection* catch missing methods

simpler implementation but same perf i guess

not much room for smarts in my soln though