This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-12-20
Channels
- # adventofcode (29)
- # announcements (7)
- # aws (1)
- # babashka (3)
- # beginners (43)
- # biff (20)
- # clj-kondo (44)
- # cljs-dev (20)
- # clojure (74)
- # clojure-europe (24)
- # clojure-finland (2)
- # clojure-nl (13)
- # clojure-norway (3)
- # clojurescript (31)
- # code-reviews (1)
- # community-development (12)
- # cursive (3)
- # datomic (6)
- # emacs (1)
- # fulcro (25)
- # interop (7)
- # introduce-yourself (2)
- # leiningen (30)
- # nbb (3)
- # overtone (1)
- # podcasts-discuss (5)
- # polylith (24)
- # practicalli (1)
- # reclojure (1)
- # reitit (13)
- # rum (7)
- # shadow-cljs (12)
- # sql (23)
- # squint (51)
- # test-check (1)
- # testing (2)
- # tools-deps (2)
Any better ways to measure the time a mutation takes than to use the browser profiler? Any way to fire a callback when fulcro has finished rendering after the db changed?
Hmm. Perhaps checking the clock in another transaction, that the first one fires with :after-render? true
?
Could be called like (transact! this [(measurement-start) (transaction-to-measure)])
and then measurement-start takes note of the time, queues measurement-end after the render, and that in turn will again check the time and print the result
Timing things is a fun task in browsers. Remember that in dev mode there is a lot of stuff “billed to” the mutation that isn’t your code or even production-necessary code: serializing new stuff to Inspect, logging stuff, React is in dev mode.
Also, which transaction alg you’re using. The sync transaction support will have a MUCH lower overall latency from call to transact to the render result.
Yeah, inspect takes a heavy toll, when a lot of data is put into the db, but also really simple to turn off while doing that. Wasn't even aware that transaction can be tweaked. Had read only about the renderers
I already got pretty happy results, though I admit that there was nothing very surprising. Biggest surprise was that putting derived state into the db to avoid calculating it five times, actually resulted to even better than five time speedup. I don't know if the GC got happier, or what was going on
This is a useful shadow cljs config:
:performance-dev {:target :browser
:output-dir "resources/public/js/main"
:asset-path "/js/main"
:js-options {:ignore-asset-requires true
:resolve {"react-dom" {:target :npm
:require "react-dom/cjs/react-dom.production.min.js"}
"react" {:target :npm
:require "react/cjs/react.production.min.js"}}}
:modules {:app {:entries [app.client]}}
:devtools {:after-load app.client/refresh}
:compiler-options {:closure-defines {goog.DEBUG false}
:external-config {:fulcro {:html-source-annotations? true}}}}
(modify the modules and devtools)And the measurements didn't stay stable over different compilations with same code, changing with tens of percents, while somewhat stable as long as shadow didn't redo anything
I’ve had pretty good luck with chrome profiler using that config…at least for finding the hot spots
It's workable. Just wish there was better tooling to limit the profile to relevant parts. Like you can do with the flamegraph page clj-async-profiler gives
Hm, can't find anything even on :external-config. Not on shadow's nor on clojurescript compilers pages. And google is singularly useless, finding anything that is even close to those. What does that do?
Found the relevant parts, so that's a place where people just seem to put stuff for their own configuration during cljs compilation, and then where fulcro uses that in dom.clj. Just need to figure out what it means in this case 😉