Size Change: +8 B (0%)

Total Size: 1.22 MB

_{compressed-size-action}

I'm not sure if the performance tests are the ideal way to see the performance of individual functions. I'd consider that more for a larger refactoring where a benchmark isn't possible.

For this, the scope is so small that it might be better to benchmark the individual functions, passing in some dummy data and timing how long the functions took (averaged over multiple runs).

It could be a fairly homebrew benchmark, just using something like performance.now. Or there are some third party services that allow comparison of two bits of code (jsperf, jsbench etc.).

Thanks for following up @ZebulanStanphill

In my reading of codehealth. the impact of this change on the "focus" metric was about 10% slower. That said, 10% is small enough that it's hard to know on a single PR whether it's a stable improvement or error margin. The only way to know for sure is to actually merge and check the trend in the next commits in http://codehealth.vercel.app

@talldan I'm also not sure that checking the performance of the function directly will give any clue here because there's so many factors (number of times it's called, the arguments, the pre-rendering... ) that can impact the measure.

Personally, given that the initial numbers of the "focus" metric in the performance tests of this PR are "promising", I think we should try it. Merge it and monitor the metric over the next commits in trunk.