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.

so many competing concerns in code 😜

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.

oh bummer…yeah, the macroexpansion does include it

no no…this isn’t a macro problem

this is a me problem 😄

haha 🙂

If you change your code to pass a map it’ll macroexpand and be fast

(dom/ul {} ...)

I'll try

same on li

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.

you sure you don’t have instrument on or something?

and you put a props map on ul and li?

no sorry it's still from do-not-use/conform!

(dom/ul {}
                   (for [i (range 1 100)]
                     (dom/li {} (str "Index " i)))))

this is a fresh project so no instrumentation or anything should be activated.

ok, I’ve opened an issue…try it with normal DOM just for my sanity as well

ok

Regular dom does not call conform and frame_render/render! takes about 50 ms instead of 250 ms

ok, and without {}?

(thanks for checking, BTW)

The same result without {}, no conforms.

You're very welcome, thank you for looking into it.

ok, so the regular DOM is fast

but localized dom is not

I’ll move the issue

If I just update the component, the difference is 80 ms to 8 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.

i.e. there are tons of workarounds that are easy

and I have much more pressing things to do with my 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

later using gobj/get "operation" would fail to find it

I realize this is a very vague question, just wondering if the symptoms are something that anyone as seen before

Yeah it stops working

(dom/button {:onClick (fn [] (js/console.log "blah")} "Foo")

for example..

that one should not be affected

and I do advanced builds regularly.

yeah same here, very odd behavior for sure

I would assert that the real example of a broken one is not that code

@maxt what part of that 8ms is actually the DOM calls vs React overhead?

any idea?

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

Running 3x in a REPL, I mean, not in a loop

better to put the time/loop in a function so that the js VM can optimize it

you might see it get faster over multiple calls

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

This is also all development builds

on my machine 10,000 divs take 14ms once warmed up

what kind of build won’t affect that

you’re testing the perf of a function that won’t be touched by adv compile

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

If I call createElement in that same loop, on my machine, 10,000 divs take 12.3 ms

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")

@tony.kay Ok, this is the real one

Works locally, but once built stops firing :man-shrugging:

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 …)

but not a ton…goes to 22ms with the str building (.22ms for each list of 100)

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

it will vary…it’s modern hardware…name of the game

but it stabilizes some

which is why you run it mulitple times…the early measurements are usually wildly off

(because the VM hasn’t warmed up (optimized) the code yet)

Yes, I'm not worried about that at all. The ldom does take 1300 ms however 🙂

in this same test? Yeah, that is crap

Yes, just replacing the require

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.

you can easily see stuff off by a factor of 10x

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

defmethod mutate 'listing/add-additional-charge is how its defined

but I may try and move it into the UI as a test

not asking how it is defined…more where, and if there is a direct require of that ns

in dev mode you might be requiring it via alt dev paths/files

so it would work there, but not in prod

just getting the symbol right doesn’t get it installed…a require of that ns in the code does

and if there is no require, there is no install

I moved it into the same file as the ui and redefined it as a defmutation in that file. Still nothing, so odd

@tony.kay I forgot to mention this is a subform, I added these fn as computed props and it worked

I am trying to use semantic-ui-wrapper but it seems events are not translated to clojure maps. How should I convert it ?