Opts · djuleayo

Opts · djuleayo https://316c0611.personalpage-ahl.pages.dev/tags/opts/ Hugo en JS spread performance ⚠️warning https://316c0611.personalpage-ahl.pages.dev/posts/spread-performance/ https://316c0611.personalpage-ahl.pages.dev/posts/spread-performance/ Thu, 15 May 2025 17:10:43 +0200 <h1 id="js-spread-performance-warning"> JS spread performance ⚠️warning <a class="heading-link" href="#js-spread-performance-warning"> Link to heading </a> </h1> Us web devs, we often speculate syntax based on &ldquo;best practices&rdquo; bestowed upon us by the Gods of - meme lords. We praise our prettier and linters as basis of all success. Looping between all 22 and a half options of a drop down allows you to use exponential complexity implementations. In a loop. Because even if you have 2k entries thats a warmup for one core. So in all wire connections between types, runtime validators, component props, api responses and requests, rarely in fact implementation matters from performance standpoint. Except when it does. <blockquote> Spread operator can cost you performance</blockquote> Straight to the point. Never use it in a loop <div class="highlight"><pre tabindex="0" style="color:#e6edf3;background-color:#0d1117;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-js" data-lang="js">const buf = {} Object.keys(incomingData).forEach((entry) =&gt; { buf[entry] = { ...buf[entry], ...incomingData[entry], } }) </code></pre></div>I did this recently because of &ldquo;immutable is good&rdquo; hype. And quickly found out it has its costs, especially in this given form. Each assignment there is linear complexity to object size. Meaning doing that in loop is O(n^2). And if you have 2k entries, well, no need to imagine. Recently I did clean finger thick dust cover from my profiler start button so isn&rsquo;t that a change. Instead of speculating syntax we can actually measure Results? Parsing 2k lines of custom simple language yielded 2 drastically different results. <ul> <li>the spread in loop way went over 63 seconds</li> <li>changing just one expression from spread to property assignment yielded 0.5 seconds for the same 2k lines!!!</li> </ul> One line of code. One expression and 62/0.5 = <code>124x times faster</code>!!! Be my guest, that kind of difference becomes notable even on few tens of entries! So, yeah immer is cool, and your store wants a new reference to dispatch the changes, but that doesn&rsquo;t mean you should change it n times in a loop. As you can see. Instead keep using regular assignment and change the reference only once when needed. <div class="highlight"><pre tabindex="0" style="color:#e6edf3;background-color:#0d1117;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-js" data-lang="js">const buf = {} Object.keys(incomingData).forEach((entry) =&gt; { buf[entry] = incomingData[entry] }) </code></pre></div>Old school 👊 In conclusion, spread in a loop is almost as evil as awaiting in a loop <h1 id="js-spread-performance-warning"> JS spread performance ⚠️warning <a class="heading-link" href="#js-spread-performance-warning"> Link to heading </a> </h1> Us web devs, we often speculate syntax based on &ldquo;best practices&rdquo; bestowed upon us by the Gods of - meme lords. We praise our prettier and linters as basis of all success. Looping between all 22 and a half options of a drop down allows you to use exponential complexity implementations. In a loop. Because even if you have 2k entries thats a warmup for one core. So in all wire connections between types, runtime validators, component props, api responses and requests, rarely in fact implementation matters from performance standpoint. Except when it does. <blockquote> Spread operator can cost you performance</blockquote> Straight to the point. Never use it in a loop <div class="highlight"><pre tabindex="0" style="color:#e6edf3;background-color:#0d1117;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-js" data-lang="js">const buf = {} Object.keys(incomingData).forEach((entry) =&gt; { buf[entry] = { ...buf[entry], ...incomingData[entry], } }) </code></pre></div>I did this recently because of &ldquo;immutable is good&rdquo; hype. And quickly found out it has its costs, especially in this given form. Each assignment there is linear complexity to object size. Meaning doing that in loop is O(n^2). And if you have 2k entries, well, no need to imagine. Recently I did clean finger thick dust cover from my profiler start button so isn&rsquo;t that a change. Instead of speculating syntax we can actually measure Results? Parsing 2k lines of custom simple language yielded 2 drastically different results. <ul> <li>the spread in loop way went over 63 seconds</li> <li>changing just one expression from spread to property assignment yielded 0.5 seconds for the same 2k lines!!!</li> </ul> One line of code. One expression and 62/0.5 = <code>124x times faster</code>!!! Be my guest, that kind of difference becomes notable even on few tens of entries! So, yeah immer is cool, and your store wants a new reference to dispatch the changes, but that doesn&rsquo;t mean you should change it n times in a loop. As you can see. Instead keep using regular assignment and change the reference only once when needed. <div class="highlight"><pre tabindex="0" style="color:#e6edf3;background-color:#0d1117;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-js" data-lang="js">const buf = {} Object.keys(incomingData).forEach((entry) =&gt; { buf[entry] = incomingData[entry] }) </code></pre></div>Old school 👊 In conclusion, spread in a loop is almost as evil as awaiting in a loop