Update UnderstandingTiming.md

This commit is contained in:
Mike Thompson 2018-02-17 20:28:44 +11:00 committed by GitHub
parent a0d2b14059
commit 108f237111
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 12 additions and 12 deletions

View File

@ -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 Click the "replay" button ([#115](https://github.com/Day8/re-frame-trace/issues/155)) a few times to see if you
get stable numbers. 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 After all, you're running a dev build, right, not the
production build? And I'm guessing you're also production build? And I'm guessing you're also
running a dev build of React? 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.
And using `re-frame-trace` will slow things
down too, what with all that creating and analysing of trace.
So, run the production version of your app first, before So, run the production version of your app first, before
deciding you have a performance problem. Something what 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 The Timing Tab is not really about absolute numbers so
much as the relative time taken to do the different much as the relative time taken to do the different
"parts" of an Epoch. Is one View very slow for some "parts" of an Epoch. Is most the time going in views, or
reason, compared to others? maybe one view in particular? Or in
one subscription, compared to the others?
And, even then, remember point 1 (above). And, even then, remember point 1 (above).
## Know Your Epoch Timeline ## Know Your Epoch Timeline
@ -41,10 +40,11 @@ over time, within the browser.
## Other Tips ## Other Tips
You should probably have [React DevTools](https://github.com/facebook/react-devtools) It might be useful to 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, installed because it can show you visually, what is rerednering. Neat idea. But, realise it
so disable it when trying to get more accurate timing figures. 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) 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.