Hmm, I find this question a bit hard to answer without more code. I think I need to see the actual subscriptions (and maybe components) in order to understand it properly. However, https://github.com/Day8/re-frame-trace is pretty nice for measuring performance of you subscriptions and event handlers.

What kinds of performance considerations you are concerned about? I'm only seeing a couple of map lookups -- all seems pretty benign.

@mikethompson Are you saying a subscription the entire db isn’t that ‘wrong’ if all it involves is a map lookup? That’s what I wanted to know, because I would only refactor this if it really mattered for performance.

@U0J30HBRS Going to check out re-frame-trace, thanks

@U04V15CAJ any subscription which depends directly on app-db will rerun every time app-db changes. So make them trivial. Map lookups are trivial.

@U04V15CAJ if you use the latest version of re-frame-trace you'll ALSO have to be using re-frame v0.10.3-alpha1

@mikethompson Another consideration would be how often a subscription would run. If I can refactor the structure of the db so that the subscription will run less often, this will be better I guess. But if it’s worth it, I can check with re-frame-trace.

E.g. in my Stackoverflow question, if I would move the routes to [:widget/base :routes] each page would have a subscription on [:widget/base :routes page-id] and the wrapping widget would have a subscription on [:widget/base :routes cur-page-id], avoiding subscriptions on the entire db

@mikethompson What happens when the db changes? The entire state has to be compared to the previous state. Is this a cheap operation?

No, you misunderstand the process

I mean within a subscription

The Layer 2 subscriptions WILl run each time app-db changes.

No question. They will run. So we make them trivial

If the values they extract (from app-db) test =` to "last time", then no further propogation though the signal graph will occur

So all Layer 2 subscription will run when app-db changes in any way.

But we put serious computation in layer 3

And layer 3 subsciptions never run unless the value of their (layer 2) input signals change.

Ah, so layer 2 subscription will always run. That makes sense, because the db will have changed anyway. But they select a subtree of the db that are used in level 3 and this has to be compared to the previous selection. Which can still be a quite large map.

Although = is used to test if "this time" is the same as "last time", you'll note that the implementation of = shortcuts of the two are identical?

Making the = test trivial

Right.

So the rules are simple: 1. make layer 2 subscriptions trivial extractors. 2. Realise that layer 2 subscriptions run every time app-db changes 3. know that "propogation" of values through the signal graph will stop the moment that a value tests = to last time (ie. nothing has changed). 4. Know that an = test is shortcut to true when its two operands are identical?. So if "this time" is identical? to "last time", the test to stop propagation is really fast.

Are we there :-)

Yeah

@mikethompson One more question: who triggers the subscriptions. Is it level 2 saying: my content changed, so I trigger who are subscribed to me? If that is true, they must check themselves against their previous state, no?

This can still be cheap because if identical?, just wondering

If the input signals (subscriptions) are the same as last time, a node doesn't recalculate. A "node" can be either a layer in the signal graph OR the eventual view fucntion.

its all more than efficient enough.

Thanks for the patience 🙂

np

I installed re-frame-trace and all subscriptions show 0.0-0.2 ms. Guess it’s fine.

@mikethompson We’re stuck at D3 3.5 but it still seems to work with that 🙂