re-frame-10x/docs/HyperlinkedInformation/UnderstandingTiming.md

Some notes on the "Timing" tab in `re-frame-trace`.

## Be Sceptical Of The Numbers

Two reasons:

1.  Accurately timing something in the browser is almost
    a fool's errand. One moment it takes 1ms and the next it 
    takes 10ms, and you’ll never know why. Noisy.

    So, don't ever base decisions on one set of timings.
    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.

    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.
    
    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.
    
    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?
    And, even then, remember point 1 (above). 
    
## Know Your Epoch Timeline

The Timing Tab is easier to understand once you have internalised the 
following graphic which shows how, operationally, the six dominoes play out, 
over time, within the browser.  

<img src="https://raw.githubusercontent.com/Day8/re-frame/master/images/epoch.png">

## 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.

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.
-												Update UnderstandingTiming.md
											
										
										
											2018-02-17 18:59:29 +11:00
+								Some notes on the "Timing" tab in `re-frame-trace`.
-												Improve Hyperlinked docs by adding something on Timing panel

											
										
										
											2018-01-20 16:50:59 +11:00
-												Update UnderstandingTiming.md
											
										
										
											2018-02-17 18:59:29 +11:00
+								## Be Sceptical Of The Numbers
-												Improve Hyperlinked docs by adding something on Timing panel

											
										
										
											2018-01-20 16:50:59 +11:00
-												Update UnderstandingTiming.md
											
										
										
											2018-02-17 18:59:29 +11:00
+								Two reasons:
-												Improve Hyperlinked docs by adding something on Timing panel

											
										
										
											2018-01-20 16:50:59 +11:00
 .  Accurately timing something in the browser is almost
 								    a fool's errand. One moment it takes 1ms and the next it
-												Docs tweaks

											
										
										
											2018-01-20 17:00:40 +11:00
+								    takes 10ms, and you’ll never know why. Noisy.
-												Improve Hyperlinked docs by adding something on Timing panel

											
										
										
											2018-01-20 16:50:59 +11:00
-												Update UnderstandingTiming.md
											
										
										
											2018-02-17 18:59:29 +11:00
+								    So, don't ever base decisions on one set of timings.
-												Update UnderstandingTiming.md
											
										
										
											2018-02-17 20:22:35 +11:00
+								    Click the "replay" button ([#115](https://github.com/Day8/re-frame-trace/issues/155)) a few times to see if you
-												Update UnderstandingTiming.md
											
										
										
											2018-02-17 18:54:43 +11:00
+								    get stable numbers.
-												Improve Hyperlinked docs by adding something on Timing panel

											
										
										
											2018-01-20 16:50:59 +11:00
-												Update UnderstandingTiming.md
											
										
										
											2018-02-17 18:54:43 +11:00
+.  Don't freak out about any apparent slowness just yet.
-												Improve Hyperlinked docs by adding something on Timing panel

											
										
										
											2018-01-20 16:50:59 +11:00
-												Docs

											
										
										
											2018-01-20 17:11:10 +11:00
+								    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?
-												Improve Hyperlinked docs by adding something on Timing panel

											
										
										
											2018-01-20 16:50:59 +11:00
-												Docs

											
										
										
											2018-01-20 17:11:10 +11:00
+								    And using `re-frame-trace` will slow things
-												Improve Hyperlinked docs by adding something on Timing panel

											
										
										
											2018-01-20 16:50:59 +11:00
+								    down too, what with all that creating and analysing of trace.
-												Docs

											
										
										
											2018-01-20 20:20:36 +11:00
+								    So, run the production version of your app first, before
 								    deciding you have a performance problem. Something what
-												Improve Hyperlinked docs by adding something on Timing panel

											
										
										
											2018-01-20 16:50:59 +11:00
+								    takes 100ms in dev might take 20ms in prod.
-												Docs

											
										
										
											2018-01-20 20:20:36 +11:00
+								    The Timing Tab is not really about absolute numbers so
-												Docs

											
										
										
											2018-01-20 17:11:10 +11:00
+								    much as the relative time taken to do the different
-												Docs

											
										
										
											2018-01-20 20:20:36 +11:00
+								    "parts" of an Epoch. Is one View very slow for some
-												Docs

											
										
										
											2018-01-20 17:11:10 +11:00
+								    reason, compared to others?
 								    And, even then, remember point 1 (above).
-												Improve Hyperlinked docs by adding something on Timing panel

											
										
										
											2018-01-20 16:50:59 +11:00
-												Update UnderstandingTiming.md
											
										
										
											2018-02-17 18:59:29 +11:00
+								## Know Your Epoch Timeline
-												Improve Hyperlinked docs by adding something on Timing panel

											
										
										
											2018-01-20 16:50:59 +11:00
-												Tweak docs to fit in with new Infographic

											
										
										
											2018-01-20 21:21:14 +11:00
+								The Timing Tab is easier to understand once you have internalised the
 								following graphic which shows how, operationally, the six dominoes play out,
 								over time, within the browser.
-												Improve Hyperlinked docs by adding something on Timing panel

											
										
										
											2018-01-20 16:50:59 +11:00
 								<img src="https://raw.githubusercontent.com/Day8/re-frame/master/images/epoch.png">
-												Update UnderstandingTiming.md
											
										
										
											2018-02-17 18:59:29 +11:00
+								## Other Tips
-												Docs

											
										
										
											2018-01-20 20:20:36 +11:00
 								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,
-												Work on the README for tone.

											
										
										
											2018-01-21 10:54:13 +11:00
+								so disable it when trying to get more accurate timing figures.
-												Docs

											
										
										
											2018-01-20 20:20:36 +11:00
 								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)
-												Update UnderstandingTiming.md
											
										
										
											2018-01-22 14:13:04 +13:00
+								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.