Add console text output tab #262
Conversation
|
Having looked at nothing yet--I assume the massive slowdown for live updates comes from React and rerendering all the time; is it possible we could escape-hatch this by doing some set-inner-html nonsense? Not saying it'd be a good idea, mind, but... |
|
Hm, I thought the slowdown was also on the worker thread, but you may be right. I’ll try tomorrow through the innerHTML side door |
|
No idea if it would help/how much. In the screenshotted example I'm noticing a slowdown of ~2.5 seconds per run over 4-5 runs, for 4 chains, 1k warmup 1k samples, radius 2. (That about doubles the wall clock time, but it's a trivial example.) Whereas for the SIR model example, with 100 samples, it's a negligible amount--much less than the inter-run variation without the print statement. |
| const { draws, paramNames, computeTimeSec, samplingOpts } = latestRun; | ||
| const { samplingOpts, runResult } = latestRun; | ||
| if (!runResult || !samplingOpts) return <span />; | ||
| const { draws, paramNames, computeTimeSec, consoleText } = runResult; |
There was a problem hiding this comment.
If this line doesn't die when runResult is undefined, then I think it might be clearer to keep the early <span /> return closer to the actual-component return, i.e. move the current l31 to l33.
|
For posterity: innerHTML trickery was faster than reactivity for live streaming of output, but was still a decent factor slower than I think we'd be willing to tolerate |
Closes #260
I ended up not doing something live because this would dramatically slow down the sampling if a print statement was present in the model block. Now it only slightly slows it down, at the cost of not being live. If a user really wants to monitor the output live, they still can use the developer console.