This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-05-26
Channels
- # announcements (2)
- # babashka (55)
- # beginners (107)
- # calva (65)
- # cider (5)
- # clara (4)
- # clj-kondo (17)
- # cljs-dev (38)
- # cljsrn (16)
- # clojure (117)
- # clojure-australia (8)
- # clojure-europe (13)
- # clojure-italy (4)
- # clojure-nl (5)
- # clojure-provo (2)
- # clojure-sweden (9)
- # clojure-taiwan (1)
- # clojure-uk (41)
- # clojurescript (40)
- # code-reviews (1)
- # conjure (40)
- # cursive (4)
- # datomic (11)
- # events (2)
- # fulcro (33)
- # graalvm (1)
- # jobs (2)
- # jobs-discuss (19)
- # lsp (18)
- # off-topic (58)
- # polylith (2)
- # quil (2)
- # react (28)
- # reagent (35)
- # reitit (3)
- # remote-jobs (1)
- # ring (9)
- # sci (76)
- # shadow-cljs (19)
- # sql (10)
- # testing (5)
- # vim (13)
- # xtdb (5)
not exactly cljs dev question: Curious if there were any attempts at improving transit-js performance? Looking at the source it seems like the algorithm recursively walks parsed JSON tree, which suggests that it could be more performant w/o recursion, since recursion is typically slower in JS engines (?).
@roman01la I don't think many people actually use transit-js
which makes sense, transit is only really popular in clojure and clojure is a relatively small community
yeah, I’m referring to transit-js specifically, because it’s where the core of it is, transit-cljs is more of a wrapping library
the reason why I’m asking is because while parsing is fast, it’s still not fast enough in envs such as React Native or for real-time/streaming type of web apps, where updates are being consumed frequently and transit parsing periodically blocks the main thread
what other tech is fast enough in this scenario? (just looking to learn here)
it is likely a significant effort to implement the transit design in a streaming fashion, so I'm kind of wondering out loud if even that would be fast enough for the scenario you're asking about and whether there are known alternatives that meet the criteria (like, is streaming json sufficient?)
@alexmiller I don’t have an answer for this in a form of a working library, but in our case we are not sending custom data types over the wire except of UUID. @mfikes I’m wondering if a modified version of cljs-bean (that would recognize UUIDs) could make a difference?
@mfikes nice! but that’s only writing to transit, right?
@alexmiller I don’t think streaming parsing will be faster or even comparable to the current implementation. However would be interesting to see how performance would change with a non-recursive implementation, afaik JS engines are not that good at recursion, I might be wrong though.
that seems like an overly generic conjecture with an absence of data :)
this is the sort of thing that may be true at a point in time, then becomes conventional wisdom, but the enormous performance pressures on js engines completely invalidate over time. but I don't have any clue either way
@roman01la strawman - try and find a json parser that is fast enough for your use case
that would give a jumping off point to figure out where transit-js can improve / there is room for a different impl of the spec
@roman01la it would be interesting to figure out if that it would be faster but I think it would be a significant amount of work
the other thing is that transit-js is currently unsuitable for streaming - so dropping the recursion seems a bit dubious to me vs. just doing something better (suited)
back when I worked on none of the JS streaming parsers seemed practical - that assumption may not be true anymore
it also of course leads to a different API which isn't necessary in many circumstances and a big pain
i.e. the streaming parsers - one big problem is that you need a sensible event loop thing but a lot of JS environment aren't going to give you that out of the box
it's an old version of transit but there haven't been any performance related changes since the first version
but using the latest FireFox converting 53K of JS is only 0.10 ms more than the equivalent payload of JSON (i.e. duplicated keys)