The fact that the Safari result appears to have two linear fits doesn't surprise me at all. Apple has a history of implementing multiple concrete classes for different sizes for the same abstract class. It has been known that NSArray and CFArray will switch the underlying data structure once it grows past a certain size: <a href="https://ridiculousfish.com/blog/posts/array.html" rel="nofollow">https://ridiculousfish.com/blog/posts/array.html</a> Now I'm not saying this NSArray trick was what happened here: it clearly is not because otherwise we'd see a quadratic curve followed by a linear curve. I'm just saying the data structure seems to have changed at a certain size cutoff.
An optimized implementation (as "padStart") is in the standard library now: <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/padStart" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...</a>
> But the principle remains, that it was actually completely impossible for us to analyze left-pad’s performance without a deep understanding of the specific underlying Javascript VM we cared about (or, in my case, resorting to brute experiment!).<p>And this is why we benchmark before optimizing
It had been optimized (and deprecated) since then. See <a href="https://github.com/left-pad/left-pad/blob/master/index.js" rel="nofollow">https://github.com/left-pad/left-pad/blob/master/index.js</a>
I am wondering if the graph that shows Safari performance is actually quadratic. I am referring to the the 2nd linear segment.<p>On that graph, 400,000 length required 2500 in time. If it's quadratic, 800,000 would require 10,000 in time. If you imagine the plot goes all the way to 800,000 - it's not hard to see that the line/curve hitting at 10,000.<p>Thoughts?
After pre-creating a pad-string constant of sufficient length, no loop is needed. For each target$, calculate how long the needed pad is, grab that many characters, and prepend.