This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-06
Channels
- # announcements (3)
- # beginners (83)
- # calva (11)
- # cider (24)
- # cljdoc (2)
- # cljs-dev (1)
- # clojure (216)
- # clojure-berlin (1)
- # clojure-dev (18)
- # clojure-europe (8)
- # clojure-italy (5)
- # clojure-losangeles (2)
- # clojure-nl (4)
- # clojure-spec (34)
- # clojure-uk (75)
- # clojuredesign-podcast (12)
- # clojurescript (33)
- # clojutre (13)
- # community-development (1)
- # core-async (38)
- # cursive (19)
- # datomic (28)
- # duct (3)
- # emacs (1)
- # events (5)
- # figwheel-main (3)
- # fulcro (93)
- # kaocha (20)
- # lambdaisland (2)
- # off-topic (40)
- # pathom (17)
- # pedestal (8)
- # quil (1)
- # re-frame (14)
- # reitit (19)
- # shadow-cljs (34)
- # sql (8)
- # tools-deps (6)
- # vim (1)
- # xtdb (8)
- # yada (18)
I'm seeing slow renders caused by calls to com.fulcrologic.fulcro.algorithms.do-not-use/conform!
when using localized-dom. I have a repro here https://github.com/maxthoursie/fulcro3-conform-repro 175 ms of a 280 ms render is spent conforming. I think conform is only meant to be called during macro expansion, so I think the bug is that it's somehow leaking into cljs, but I haven't got further in understanding why it's happening.
The repro component is just a
(dom/ul (for [i (range 1 100)]
(dom/li (str "Index " i))))
@maxt hm…yeah, I thought that call was limited to uses in the macro expansion..it is a bug if it is being called at runtime.
The spec warnings for macros in fulcro have been really helpful. It's a little scary though that it apperently is easy to make it leak.
if you don’t pass a map, then it has to use the function version…and the function version (incorrecly) uses conform!
Hm, it does remove the call to do-not-use/conform!, but re_conform is still getting called. 108 / 150 ms still spend in spec/re_conform.
Regular dom does not call conform and frame_render/render! takes about 50 ms instead of 250 ms
So, just FYI this is not high on my priority list. You can easily use regular DOM where you don’t need the localized classes, or destructure the classnames. Open to a PR if you wanted to work on it, but I probably won’t for some time.
Ok. I understand, and I believe your prioritization is right. I really do like the localized-dom though so I might look into it.
Has anyone seen an issue where after building a production version (running through closure compiler) of a Fulcro app that click handlers stop randomly working?
@njj that probably means that you used a name in inconsistent ways where it did not get renamed in some places, but did in others….depends on what you mean by “random”. If you mean “some stop working”, then that could be it. For example, if you make an onclick in your initLocalState and store it using (set~ (.-operation this) ...)
then operation
can get renamed
I realize this is a very vague question, just wondering if the symptoms are something that anyone as seen before
Thomas Heller had done some performance tests a while back and the macro versions of Fulcro (which result in raw react calls) were about as fast as they could be…but 8ms for 100 li
sounds large to me
unless that is an initial DOM render…in which case most of that is probably actual DOM manipulation instead of just VDOM stuff
wrapping a time
around a call that makes 10,000 (or more) of those 3+ times and averaging might be a better measure of the Fulcro overhead
Yeah I wouldn't use those number to judge the performance overhead of fulcro, those where just for comparing dom and ldom. But of the 8 ms, about 1 is commit, 3 is spend in something called mark. render_Person takes about 2.5 ms
I get the same time w or w/o the props map, but I’m using a string child…so the macro detection is getting it
so about a 10% difference…and actually now that I re-run the Fulcro example, I’m measuring more like 12.5 to 13.5…so within the realm of statistical error
(dom/button
:.btn.btn-link
{:onClick (fn [] (prim/transact! this
`[(listing/add-additional-charge {:charge-type ~charge_type :inventory-id ~inventory-id :charge-id ~(prim/tempid)})
:listing]))} "Add More")
and your li
example takes about 180 microseconds (18ms to render 100 items 100 times / 100 times) when measured this way. Your string building adds overhead (str …)
the extra overhead, internally, is the fact the that children are being “forced” (expanded from a seq to a js array)
If I repeat your example, i get around 20 ms, but it varies much, and I can't see any real difference between react and dom
which is why you run it mulitple times…the early measurements are usually wildly off
ok…I just wanted us to be speaking the same language on how to measure performance. The flame charts are a nice check…but isolated testing like this is much more accurate.
general procedure: isolate, then put in function, run a few times until relatively stable, then run a few more and avg…you can be more “formal” about it (and there is a lib that does this called https://github.com/hugoduncan/criterium for the JVM), but the procedure I just outlined does well enough for pragmatic purposes.
@njj The only thing I can think of is that perhaps your mutation add-additional-charge
is somehow not getting required in your prod build
remember that mutations are implemented with a multimethod, and if the multimethod does not run, it won’t be available to fulcro
not asking how it is defined…more where, and if there is a direct require of that ns
just getting the symbol right doesn’t get it installed…a require
of that ns in the code does
I moved it into the same file as the ui and redefined it as a defmutation
in that file. Still nothing, so odd