1

I recently discovered a bottleneck in a web application. I was able to whittle down to where it is, by adding some Jest tests which use performance.now() to roughly time the function execution.

 test(...
    const avg = Array(numberOfReps).fill(null).reduce((agg)=>{
                const m0 = performance.now();
                doThing();
                const m1 = performance.now();  
                return agg + ((m1 - m0)/numberOfReps);
            }, 0)  
)

In most cases, I would be comfortable stopping here. But, the bottleneck is in a part of the application that will be used a lot. And, while memos have helped, first-run speed is also very important.

I need to be confident within 2 sigma at 20% that the times reported by my tests are accurate. For example, if my tests report 1000 ms execution, I need to know that 95 percent of executions of size n fall between 800 and 1200 ms.

Does performance testing a la above in Jest fit this bill? I haven't yet been able to find any useful answers elsewhere.

Edit: I'm aware performance.now() is accurate. But, I'm wary that Jest might inject plugins or use some kind of bus that makes the total time less accurate, i.e., executes other functions between m0 and m1. Is that a valid concern?

lmonninger
  • 831
  • 3
  • 13
  • @HereticMonkey That doesn't exactly answer my question. See edit. – lmonninger Sep 17 '21 at 14:03
  • You won't have to worry about jest messing up your timings in the example provided – Joe Lissner Sep 17 '21 at 14:04
  • @JoeLissner When would I? – lmonninger Sep 17 '21 at 14:05
  • That post is about timing execution in JavaScript. If you take the time to read the accepted answer, and its comments, you may discover the perils of micro-optimizations like what you are attempting to do. – Heretic Monkey Sep 17 '21 at 14:10
  • @HereticMonkey I am particularly interested in what Jest might do to make the time between m0 and m1 less reflective of the function execution. Such is not addressed in the post you linked. Separately, while I'm aware optimizing in JavaScript can be unfruitful, I wouldn't consider this a micro-optimization; if timings are accurate, improvements made thusfar have already reduced initial render speed for components using the function on n > 10^4 from 5+ seconds to < 1 s -- a perceivable difference. – lmonninger Sep 17 '21 at 14:18
  • @lmonninger if you had `m0` and `m1` in different tests, then jest might get in the way – Joe Lissner Sep 20 '21 at 15:03

1 Answers1

3

PerformanceNow returns a DomHighResTimeStamp.

The time, given in milliseconds, should be accurate to 5 µs (microseconds), with the fractional part of the number indicating fractions of a millisecond. However, if the browser is unable to provide a time value accurate to 5 µs (due, for example, to hardware or software constraints), the browser can represent the value as a time in milliseconds accurate to a millisecond.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
  • Thanks! I'm aware `performance.now()` is accurate. But, I'm wary that Jest might inject plugins or use some kind of bus that makes the total time less accurate, i.e., executes other functions between `m0` and `m1`. Is that a valid concern? – lmonninger Sep 17 '21 at 14:01
  • You'd have to do some math or experimentation to find out. Apparently, you're more or less guaranteed 1ms accuracy. – Robert Harvey Sep 17 '21 at 14:09
  • Okay, great! Thank you! – lmonninger Sep 17 '21 at 14:09