Repository: You-Dont-Know-JS
Issue: Async & Performance Chapter 6 "Repetition" section
Labels: for second edition

**Yes, I promise I've read the [Contributions Guidelines](https://github.com/getify/You-Dont-Know-JS/blob/master/CONTRIBUTING.md)** (please feel free to remove this line).

I've been having lots of trouble with 3 paragraphs in this section, IMO, the whole section is too dense and short.

This paragraph:
> A straight mathematical average by itself is definitely not sufficient for making judgments about performance which you plan to extrapolate to the breadth of your entire application. With a hundred iterations, even a couple of outliers (high or low) can skew the average, and then when you apply that conclusion repeatedly, you even further inflate the skew beyond credulity.

1. Is the usage of the word "credulity" here a typo ? "credulity" is a synonym of "naivety" and "gullibility", I think the word is supposed to be "credibility" ? 

2. What does "apply that conclusion repeatedly" really mean ? Does it mean "when you increase the number of iterations, the skew will increase proportionally" ?
<br>
The next paragraph: 

> Instead of just running for a fixed number of iterations, you can instead choose to run the loop of tests until a certain amount of time has passed. That might be more reliable, but how do you decide how long to run? You might guess that it should be some multiple of how long your operation should take to run once. Wrong.

1. Why might this be more reliable ? In the previous section, it is established that there are 3 main problems with a simple "startTime, do operation, endTime - startTime" benchmark: 
A) Something could have intervened with the engine or system during that specific test. 
B) The engine could have found a way to optimize your isolated case.
C) Perhaps your timer was not precise enough, therefore you got an inaccurate result.

Using the second pattern, I believe problem A is still there, something could intervene with the engine causing an iteration of the test to take longer, therefore affecting the end result. I can't see why the engine can't find a way to optimize your tests with this pattern as well if it could do so with the first pattern, how much is it really different anyways ? 
The second problem could solve problem C, but only if the time to repeat across is a multiple of the timer's precision (e.g 30ms for a timer with 15ms precision). Otherwise you would have to increase the time to repeat across to improve accuracy, and couldn't this be achieved by increasing the number of iterations in pattern A as well ? 
<br>
And then the next paragraph: 
> Actually, the length of time to repeat across should be based on the accuracy of the timer you're using, specifically to minimize the chances of inaccuracy. The less precise your timer, the longer you need to run to make sure you've minimized the error percentage. A 15ms timer is pretty bad for accurate benchmarking; to minimize its uncertainty (aka "error rate") to less than 1%, you need to run your each cycle of test iterations for 750ms. A 1ms timer only needs a cycle to run for 50ms to get the same confidence.

I wonder what the maths behind this part is:> A 15ms timer is pretty bad for accurate benchmarking; to minimize its uncertainty (aka "error rate") to less than 1%, you need to run your each cycle of test iterations for 750ms. A 1ms timer only needs a cycle to run for 50ms to get the same confidence.

<br>
My brain is roaming in uncharted territory, so please excuse me if I am saying things that don't make any sense, but trust me, I have tried to comprehend this section for quite a while and this is my best so far, and it is all purely theoretical. I understand the basic message of this part of the book: "Use a library to benchmark your JavaScript code, it isn't as easy as it looks".