Fork me on GitHub
Richard Hundt09:06:52

Hi everyone. I've got a malli schema of around 1500 sloc, with quite a lot of :multi schemas. I'm using it for transformation, and to speed up the runtime, I'm using malli/encoder and malli/decoder , however creating these transformers takes over a minute with version 0.5.1. I'm not sure how to reason about the complexity there, as it seems like I've got some combinatorial explosion (start-up time increases non-linearly in the size of the schema). Has anyone else run into this sort of thing? Any tips? EDIT: I don't really see the need for speculative parsing or backtracking, since all the :multi schemas have discriminators which :dispatch can use to disambiguate, but there must be a lot of that going on, because plain calls to malli/decode without the "compiled" versions returned by malli/decoder take minutes themselves (not using regex schemas at all, either). 😕 (I'm running an Intel(R) Core(TM) i7-10875H)


that's not good @U026F3GM8NA. Could you create an issue out of this with a repro code showing the slowness. Thanks

Ben Sless06:07:55

@U055NJ5CC could it be related to into transformer using satisfies? It's notoriously slow and GC intensive


it could, easy to see from flamegraphs.

Ben Sless07:07:16

I can already guess from my experience with recursive calls to satisfies? , you'll see 95% of CPU is wasted on it

Ben Sless11:07:13

If -into-transformer was turned into a protocol, how would you make it work with cljs? fn? there is very different from in clj and won't be covered by a simple extend. Possible to do in cljs what was done for Schemas in clj?