Fork me on GitHub

@mikethompson: i've got a decent amount of tracing in my codebase now, and after keypress events in the component which had perf problems i see a couple of hundred reaction fns run, but no renders or other handlers triggering


that seems like reasonable operation by my understanding


meanwhile, my user who had the terrible text-entry performance has reported back that it's fixed by replacing the app-db modifying re-frame event handlers with plain reagent/atom updates


so it would seem something in my re-frame event pipeline is causing the performance problem (since the reaction-fns are run either way)... more investigation required i think


can I chain subscriptions? say sub1 depends on what sub2 produces


@mccraigmccraig: if I understand you correctly, one (or more) of those subscriptions is taking the time, then? Or perhaps some subset of them.


And the task is now to find out which one(s)?


Hmm. Thinking more ... the interesting bit is this: hundreds of subscriptions handlers are running, but no views are redrawing. So all those subscriptions must be returning identical? to what they returned last time (otherwise views would be being redrawn). Which, in turn, leads me to think that there really isn't any "computation" in these subscription handlers, they must all he "accessor" in nature (just pulling out some part of app-db)


Hmm. Further thinking ... so just to be sure ... in order to have hundreds of active subscriptions at any one point, you must have hundreds of components visible, right? Some sort of gird maybe?


@mikethompson: most of the subs are accessors... there is a list of messages visible, each of which has many local 'joins' to linked objects


i think i need to go back and link the key events back to app-db changes and see what's different