Update UnderstandingTiming.md
This commit is contained in:
parent
a0d2b14059
commit
108f237111
|
@ -12,23 +12,22 @@ Two reasons:
|
|||
Click the "replay" button ([#115](https://github.com/Day8/re-frame-trace/issues/155)) a few times to see if you
|
||||
get stable numbers.
|
||||
|
||||
2. Don't freak out about any apparent slowness just yet.
|
||||
2. Don't freak out about any apparent slowness. Not just yet, anyway.
|
||||
|
||||
After all, you're running a dev build, right, not the
|
||||
production build? And I'm guessing you're also
|
||||
running a dev build of React?
|
||||
|
||||
And using `re-frame-trace` will slow things
|
||||
down too, what with all that creating and analysing of trace.
|
||||
running a dev build of React? And even `re-frame-trace` itself will add
|
||||
its own drag too, what with all that creating and analysing of trace.
|
||||
|
||||
So, run the production version of your app first, before
|
||||
deciding you have a performance problem. Something what
|
||||
takes 100ms in dev might take 20ms in prod.
|
||||
takes 100ms in dev might take 10ms in prod.
|
||||
|
||||
The Timing Tab is not really about absolute numbers so
|
||||
much as the relative time taken to do the different
|
||||
"parts" of an Epoch. Is one View very slow for some
|
||||
reason, compared to others?
|
||||
"parts" of an Epoch. Is most the time going in views, or
|
||||
maybe one view in particular? Or in
|
||||
one subscription, compared to the others?
|
||||
And, even then, remember point 1 (above).
|
||||
|
||||
## Know Your Epoch Timeline
|
||||
|
@ -41,10 +40,11 @@ over time, within the browser.
|
|||
|
||||
## Other Tips
|
||||
|
||||
You should probably have [React DevTools](https://github.com/facebook/react-devtools)
|
||||
installed because it is useful. But, it can also add drag and noise to timing results,
|
||||
so disable it when trying to get more accurate timing figures.
|
||||
It might be useful to have [React DevTools](https://github.com/facebook/react-devtools)
|
||||
installed because it can show you visually, what is rerednering. Neat idea. But, realise it
|
||||
can also add drag and noise to timing results, so disable it when trying to get more
|
||||
accurate timing figures.
|
||||
|
||||
Here is (React 16) advice on [debugging React performance with Chrome Devtools](https://building.calibreapp.com/debugging-react-performance-with-react-16-and-chrome-devtools-c90698a522ad)
|
||||
|
||||
The [re-frame.core/debug](https://github.com/Day8/re-frame/blob/master/src/re_frame/std_interceptors.cljc) middleware is relatively slow, and runs interleaved with your application's events being processed. re-frame-trace gives you the same information in the app-db panel, but saves the calculations until after your application has finished running, so you don't get the performance cost included in your timing.
|
||||
The [re-frame.core/debug](https://github.com/Day8/re-frame/blob/master/src/re_frame/std_interceptors.cljc) interceptor is relatively slow, and runs interleaved with your application's events being processed. re-frame-trace gives you the same information in the app-db panel, but saves the calculations until after your application has finished running, so you don't get the performance cost included in your timing.
|
||||
|
|
Loading…
Reference in New Issue