This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-13
Channels
- # aleph (7)
- # announcements (3)
- # babashka (29)
- # beginners (70)
- # calva (5)
- # cider (14)
- # clara (3)
- # clj-kondo (25)
- # cljs-dev (2)
- # clojure (237)
- # clojure-conj (3)
- # clojure-europe (6)
- # clojure-italy (14)
- # clojure-nl (4)
- # clojure-uk (40)
- # clojurescript (29)
- # clojurex (1)
- # code-reviews (2)
- # cursive (3)
- # datascript (1)
- # fulcro (11)
- # graalvm (4)
- # graphql (12)
- # jackdaw (1)
- # jobs (1)
- # joker (22)
- # london-clojurians (1)
- # off-topic (132)
- # re-frame (38)
- # rewrite-clj (11)
- # shadow-cljs (200)
- # spacemacs (1)
- # sql (67)
- # tools-deps (15)
Funny thing, I just tried running the Lacinia benchmarks where there's no ResolverResultImpl, instead resolve-as creates a ResovlerResultPromise and immediately delivers the value to it. Guess how much that affected the benchmarks?
it's really a tiny uptick. I wonder if there's a difference in real code? And does that mean it might make sense to remove
Ultimately, probably safest to keep the code as is, but the optimizations are relatively inconsequential, which is a surprise. I would have thought it would have been more of a double-digit percentage jump in execution time.
Is the code available in a specific branch? I could try to compare it to the latests released version.
I'll push what I have. I actually went further and removed the optimizations that assume a ResolverResult (not a RRPromise).
I try to do several runs with the released version tonight, if it goes well (I did some changes) I can run the branch the next night.