Thanks for replying so quickly.
Ad 1. What do you mean by "full re-render"? I'd assume that render or
render-state is called on every component? But I could verify today that seems
not to be the case.
Ad 3.
a:
(om/update! cursor [:foo :a] 32)
(om/update! cursor [:foo :b] 32)
(om/update! cursor [:foo :c] 32)
;...
b:
(om/transact! cursor :foo #(merge % {:a 32 :b 32 :c 32 ;...
}))
I'd assume that a: takes more time because om has to determine which components
are affected wakling through the app-state many times while in b: it only has
to make that check once.
So you are saying that the cost of this check is irrelevant in comparison to
the rendering cost? Would it still be worthy to optimize for b: in cases of
very extreme updating?
On Thursday, June 4, 2015 at 3:04:31 PM UTC+2, David Nolen wrote:
> On Thu, Jun 4, 2015 at 7:26 AM, Leon Grapenthin <[email protected]> wrote:
>
>
> 1. In Annas conj talk, she asserts that "you loose the reference equality
> check" if you use swap! instead of transact!.
>
>
>
> How so? A quick skim over the source code of om tells me that transact!
> translates to a call to swap! on the app-state atom.
>
>
>
> I see that there are other good reasons to use transact!, but is performance
> really one of them or is this related to an older version of om?
>
>
>
> If you use transact! there's more information about what has changed. I
> discouraged people from using swap! as swap! will always require a full
> re-render.
>
> 2. Are there, or are there going to be significant differences in the
> performance characteristics of these calls:
>
>
>
> a: (om/update! cursor [:foo :bar] :baz)
>
> b: (om/transact! cursor #(assoc % [:foo :bar] :baz))
>
>
>
> No.
> 3. If I have a service that frequently updates the app-state, do I gain or
> loose performance by caching updates for some time to commit the changes in a
> single call to om/update!, replacing an outdated value in the cursor, or
> would it have better or worse performance to do many small updates as soon as
> they are available?
>
>
>
> Doesn't really matter. There is a render loop that attempts to render at
> 60fps. Updates are always batched and never immediately cause re-rendering,
> only re-rendering scheduling.
>
>
> David
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/clojurescript.
