6 ms·

I remember doing this back in 2006 before Chrome even came out. Remember when it was a good idea to cache the .length property because it was O(N) on some brow

I remember doing this back in 2006 before Chrome even came out. Remember when it was a good idea to cache the .length property because it was O(N) on some browser (I think an early IE), so you'd write your for-loops like this? for (var i = 0, len = arr.length; i < len; ++i) { ... } Hell, the whole premise for React (the virtual DOM) is based on outdated performance advice. Chrome has used a dirty-bit for DOM manipulations since a year or two after React came out; manipulating the DOM is within a factor of ~2-4 of setting a property on a JS object (and much faster than constructing & copying whole new JS objects, which incurs a GC cost), it's just that you really want to avoid interspersed manipulations & queries, which force a page reflow: parent.appendChild(document.createElement('div')); // Fast; ~50 us let w = parent.innerWidth; // Slow, forces reflow; ~20 ms let h = parent.innerHeight; // Fast again; no page modifications parent.appendChild(document.createElement('div')); // Fast; just sets dirty bit parent.appendChild(document.createElement('div')); // Still fast; dirty bit already set But that's the nature of a lot of technical rules of thumb. They get stale as the underlying stack beneath them changes.

blymphony 6y ago
Isn't it a good habit to store the length of the array regardless of browser implementation? Technically, accessing a variable is simply faster than a property access on an object, and this wouldn't be a case of premature optimization either--just sound coding practice.
- adrianN 6y ago
  Any compiler worth its salt should do that optimization for you.
- nostrademons 6y ago
  They're close enough not to matter on most modern browsers - I suspect V8 actually hoists the field access out of the loop when it compiles it (loop-invariant code motion is a really well-understood compiler optimization at this point). I would definitely put this in the premature optimization bucket. It doesn't really matter nowadays anyway, because now I write my for-each loops like: for (let elem : arr) { ... } or arr.foreach(elem => { ... }); (Well, technically now I write Android & C++ code and do leadership/communication stuff, but I brushed up on my ES6 before getting the most recent job.)
  - twsted 6y ago
    But arr.foreach(elem => { ... }); is still always much slower than a for loop, having the callback call, isn't it?
    - DougBTX 6y ago
      That very much depends on how good the JIT is, certainly many AOT compilers would understand this pattern and inline the callback, resulting in very similar optimised code.
  - JZumun 6y ago
    > for (let elem : arr) { ... } Do you mean: for (let elem of arr) { ... } Unless this is a joke about writing in Java & C++ (for which the colon syntax is valid) instead of javascript.
  - mantap 6y ago
    It can only hoist the length out of a for loop if it can prove that the length doesn't change, i.e. the array isn't modified. Otherwise it does have to check it each iteration. This is pretty hard in general since any time you call an external function it could potentially have a reference to the array and modify it. I suspect the length access is just so fast that the difference between hoisting it out and not is immeasurable.
  - Jasper_ 6y ago
    for (let elem of arr) {} is actually quite a bit slower than for (let i = 0; i < arr.length; i++) {} because the people who built the JS spec decided that there should be a brand new heap object created every iteration. At the time, there was thought that escape analysis would let them optimize away this object, but from what I can tell, ten years later, engines are really bad at it. Escape analysis is a heuristic, and it needs to be conservative. And yes, this isn't a micro-benchmark. At least in my application, performance is mostly bounded from GC pauses and collection, not slow code execution. Anything to reduce your GC pressure is going to be a good improvement... but note that modern frameworks like React are already basically trashing your heap, so changing out your loops in an already GC-heavy codebase won't really do much.
- saagarjha 6y ago
  > Technically, accessing a variable is simply faster than a property access on an object A good compiler will make it so that they are largely equivalent. In C-based languages this is one of the first things a compiler will do, and I am sure that every JavaScript engine does this kind of thing too when possible (actually, it may even have an easier time doing it because it may be able to skip pointer analysis).
- austincheney 6y ago
  In cases where order doesn't matter you can avoid you can avoid the array length question all together by decrementing: let index = arr.length; do { index -= 1; console.log(arr[index]); } while (index > 0); As a side note whether it takes longer to access a variable or object property is largely superficial depending upon the size of object because it implies creating a new variable on which to store that object property. There is time involved to invoke a new variable just as there is time involved to access an object's property. As an added bit of trivia in the 1970s a software developer named Paul Heckel, known for Heckel Diff algorithm, discovered that access to object properties is faster than accessing array indexes half the time. That was in C language, but it holds true in JavaScript.
  - nostrademons 6y ago
    In 2009 we standardized on this form for all Google Search JS for-each loops, because we were literally counting bytes on the SRP: for(var i=0,e;e=a[i++];){ ... } Could result in problems if the array contained falsey values, but we just didn't do that. Nowadays, like I mentioned above, I'd just do arr.foreach((elem, i) => { ... }); Which last time I checked was significantly slower than the for-loop, but I've learned my lesson about trying to optimize for browser quirks that may disappear in a year or two. :-)
  - layoutIfNeeded 6y ago
    >[...] discovered that access to object properties is faster than accessing array indexes half the time. That was in C language, but it holds true in JavaScript. What are these object properties in C?
    - austincheney 6y ago
      Hash map then.
      - layoutIfNeeded 6y ago
        Hm. So you're saying that indexing into a hash map can be faster than indexing into an array? How would this be possible? I mean, under the hood a hash map is going to an array too, which is being indexed based on the hash value...
- om2 6y ago
  If the code is hot, there is no perf difference in modern JavaScript engines. They will speculate and both your var access and length property access turn into just simple a memory read or a constant.
- olliej 6y ago
  If it can proved immutable all modern JS engines will at worst hoist to the earliest point of immutability. With the exciting amount of inlining the modern JS JITs can do they can often do a better job of proving immutability than C[++] compilers.
saagarjha 6y ago
> Remember when it was a good idea to cache the .length property because it was O(N) on some browser (I think an early IE), so you'd write your for-loops like this? I do not, mostly because I came online at a time that Internet Explorer was already uncool and Mozilla was clearly better, and also I had no idea what JavaScript was ;) But I can only imagine what the browser monoculture of the time was like, viewing the echo of it many years later with Blink.
nwienert 6y ago
The premise of React isn’t at all about performance optimization, it’s about components.
- la_fayette 6y ago
  Yes true, but why should one favor react over e.g. web-components if it is so much slower?
  - acemarke 6y ago
    React and web components are different tools trying to solve different problems. Web components are primarily about trying to add new virtual HTML tags to "extend the platform". React and other frameworks are about trying to build interactive applications that require larger-scale UI management, efficiently, on top of the DOM, by defining pieces of that UI as a tree of reusable components (and using techniques that web components don't have available to them). If I want to add a color picker to an otherwise static HTML page, I might use a color picker web component. If I want to build a meaningful-sized app, I'd reach for React.
  - kaoD 6y ago
    Web components are not built declaratively.
    - la_fayette 6y ago
      This declarative narrative is more or less a marketing gag, isn't it? Mixing Logic and Markup has always been an antipattern in web development. However, react calls this declarative and this is the new black now?
      - ricksharp 6y ago
        I’ve been doing web since 1990s and I‘ve always thought spreading a UI element across 3 separate files (often in different locations) was an anti-pattern (or 5+ files In 5 different folders if you want MVC). React is awesome because it allows feature-aligned separation of concerns (each component has a single job - render everything about a specific element - which is usually a well defined part of a specific use case). Jsx is the best UI system ever in terms of productivity - speaking from experience: I’ve implemented production apps using dozens of UI frameworks/platforms - Html, WYSIWYG, Flash, WindowsForms, WebForms, Ajax, Asp.Net Mvc, Razor, WPF, Xaml, Silverlight, Knockout, Handlebars, PhoneGap, Ionic, Bootstrap, MaterialUI, Angular2, React w/ Class Components, React w/ Mobx, React w/ Hooks I can tell you pros/cons of each of those. But at the end of the day I can develop an entire app in days in React+Hooks which would take me weeks in most any other.
lhorie 6y ago
> the whole premise for React (the virtual DOM) is based on outdated performance advice. Chrome has used a dirty-bit This mentality sorta falls into the exact pitfall GP mentioned (i.e. what you really want is for IE/Edge to be significantly faster bringing speed gains for everyone else along the way, not for Chrome to be microscopically faster at the expense of every other browser) There are real and significant costs in things like random access of .childNodes or bottom-up DOM construction in some browsers. At the height of the whole virtual dom thing, there was a lot of super browser-specific micro-optimizations going on, a lot of it w/ a heavy focus on Chrome, with IRHydra and stuff. It got a bit ridiculous when I figured out that you could make a significant dent in one of the popular benchmarks at the time not by tweaking JS anymore, but by removing unused CSS rules from bootstrap.css... But as you said, engines change quickly and I'm not sure it's really worth to be chasing micro-optimizations anymore. We're getting to a stage where the only way to get faster is to simply run less code. Some frameworks are getting the idea (svelte, marko).
- nostrademons 6y ago
  Or build better APIs into the browser and optimize them in the C++. IMHO that's the best long-term solution. Moves glacially slow, though, since there's a large engineering cost that needs the coordination of each major browser vendor. I was a big fan of Polymer/WebComponents in 2014, but they kinda dropped the ball. In hindsight I wish they'd just implemented the React API directly in the browser. (Though depending on how Google vs. Oracle goes in the Supreme Court, maybe that'll become illegal, sigh.)
  - lhorie 6y ago
    This worked amazingly well for querySelector (vs jQuery's sizzle and friends at the time), but IIRC, JIT is so good now that there are APIs written in JS _because it's faster to do so than to use AOT_. I recall reading somewhere that the cost of jumping between JS and C++ land was a source of slowdowns with the DOM API, so there's that too. But overall, I agree with the idea of incorporating the ideas that are working into the platform. There have been various discussion over the years about how virtual dom could work as a native browser API, but unfortunately, the needle hasn't moved there at all.
om2 6y ago
All browsers have used a dirty bit for layout for at least the past 2 decades (source: I have worked on browser engines for 2 decades). This is not some new Chrome thing. And all browsers continue to have that same hazard that querying layout-dependent properties forces a synchronous style recalc and layout. The benefit of React (if any; it has a lot more overhead than vanilla JS+DOM) is that you can't hit that specific pitfall of forcing layout interspersed with DOM or style manipulation.
- twsted 6y ago
  > And all browsers continue to have that same hazard that querying layout-dependent properties forces a synchronous style recalc and layout. Could you explain why? Is the following true even when the parent is already in the DOM? parent.appendChild(document.createElement('div')); // Fast; ~50 us let w = parent.innerWidth; // Slow, forces reflow; ~20 ms
  - om2 6y ago
    This is a slightly weird example because it's adding an empty <div>, so you can imagine it could be optimized if it provably has no effect on layout. But let's imagine instead that the node added to parent was a div with a text child. Or, slightly less obviously, the div is getting added in a document with a style rule of `div { width: 1000px;} In that case, the width could change. So the browser engine's options are: 1. Return a stale value from parent.innerWidth for now, and just lazily update style at the next event loop iteration. 2. Synchronously update style and layout (note, this update is not as expensive as a from-scratch layout), and return the up-to-date value of parent.innerWidth It turns out that, historically, the earliest browsers with scripting did option (2), and websites came to depend on it. So browsers had to keep on doing it, and so forth. Many folks in the web standards world would like to find away out of this dilemma, where DOM mutation doesn't risk this kind of performance hazard. You could also imagine an extra bad option: 3. Every time the DOM (or the CSSOM) is mutated, synchronously update layout. This is super expensive in the face of repeated DOM mutations. Repeated DOM mutations (e.g. adding multiple elements, setting multiple attributes) are way more common than repeatedly getting style/layout-dependent attributes. (3) has the same observable functional behavior as (2), but it's a lot slower, because it will do a lot of unnecessary layouts. I'm not totally sure if this explains everything you were wondering about, but I hope it helps some.

blymphony 6y ago

Isn't it a good habit to store the length of the array regardless of browser implementation? Technically, accessing a variable is simply faster than a property access on an object, and this wouldn't be a case of premature optimization either--just sound coding practice.

adrianN 6y ago
Any compiler worth its salt should do that optimization for you.
nostrademons 6y ago
They're close enough not to matter on most modern browsers - I suspect V8 actually hoists the field access out of the loop when it compiles it (loop-invariant code motion is a really well-understood compiler optimization at this point). I would definitely put this in the premature optimization bucket. It doesn't really matter nowadays anyway, because now I write my for-each loops like: for (let elem : arr) { ... } or arr.foreach(elem => { ... }); (Well, technically now I write Android & C++ code and do leadership/communication stuff, but I brushed up on my ES6 before getting the most recent job.)
- twsted 6y ago
  But arr.foreach(elem => { ... }); is still always much slower than a for loop, having the callback call, isn't it?
  - DougBTX 6y ago
    That very much depends on how good the JIT is, certainly many AOT compilers would understand this pattern and inline the callback, resulting in very similar optimised code.
- JZumun 6y ago
  > for (let elem : arr) { ... } Do you mean: for (let elem of arr) { ... } Unless this is a joke about writing in Java & C++ (for which the colon syntax is valid) instead of javascript.
- mantap 6y ago
  It can only hoist the length out of a for loop if it can prove that the length doesn't change, i.e. the array isn't modified. Otherwise it does have to check it each iteration. This is pretty hard in general since any time you call an external function it could potentially have a reference to the array and modify it. I suspect the length access is just so fast that the difference between hoisting it out and not is immeasurable.
- Jasper_ 6y ago
  for (let elem of arr) {} is actually quite a bit slower than for (let i = 0; i < arr.length; i++) {} because the people who built the JS spec decided that there should be a brand new heap object created every iteration. At the time, there was thought that escape analysis would let them optimize away this object, but from what I can tell, ten years later, engines are really bad at it. Escape analysis is a heuristic, and it needs to be conservative. And yes, this isn't a micro-benchmark. At least in my application, performance is mostly bounded from GC pauses and collection, not slow code execution. Anything to reduce your GC pressure is going to be a good improvement... but note that modern frameworks like React are already basically trashing your heap, so changing out your loops in an already GC-heavy codebase won't really do much.
saagarjha 6y ago
> Technically, accessing a variable is simply faster than a property access on an object A good compiler will make it so that they are largely equivalent. In C-based languages this is one of the first things a compiler will do, and I am sure that every JavaScript engine does this kind of thing too when possible (actually, it may even have an easier time doing it because it may be able to skip pointer analysis).
austincheney 6y ago
In cases where order doesn't matter you can avoid you can avoid the array length question all together by decrementing: let index = arr.length; do { index -= 1; console.log(arr[index]); } while (index > 0); As a side note whether it takes longer to access a variable or object property is largely superficial depending upon the size of object because it implies creating a new variable on which to store that object property. There is time involved to invoke a new variable just as there is time involved to access an object's property. As an added bit of trivia in the 1970s a software developer named Paul Heckel, known for Heckel Diff algorithm, discovered that access to object properties is faster than accessing array indexes half the time. That was in C language, but it holds true in JavaScript.
- nostrademons 6y ago
  In 2009 we standardized on this form for all Google Search JS for-each loops, because we were literally counting bytes on the SRP: for(var i=0,e;e=a[i++];){ ... } Could result in problems if the array contained falsey values, but we just didn't do that. Nowadays, like I mentioned above, I'd just do arr.foreach((elem, i) => { ... }); Which last time I checked was significantly slower than the for-loop, but I've learned my lesson about trying to optimize for browser quirks that may disappear in a year or two. :-)
- layoutIfNeeded 6y ago
  >[...] discovered that access to object properties is faster than accessing array indexes half the time. That was in C language, but it holds true in JavaScript. What are these object properties in C?
  - austincheney 6y ago
    Hash map then.
    - layoutIfNeeded 6y ago
      Hm. So you're saying that indexing into a hash map can be faster than indexing into an array? How would this be possible? I mean, under the hood a hash map is going to an array too, which is being indexed based on the hash value...
om2 6y ago
If the code is hot, there is no perf difference in modern JavaScript engines. They will speculate and both your var access and length property access turn into just simple a memory read or a constant.
olliej 6y ago
If it can proved immutable all modern JS engines will at worst hoist to the earliest point of immutability. With the exciting amount of inlining the modern JS JITs can do they can often do a better job of proving immutability than C[++] compilers.

saagarjha 6y ago

> Remember when it was a good idea to cache the .length property because it was O(N) on some browser (I think an early IE), so you'd write your for-loops like this? I do not, mostly because I came online at a time that Internet Explorer was already uncool and Mozilla was clearly better, and also I had no idea what JavaScript was ;) But I can only imagine what the browser monoculture of the time was like, viewing the echo of it many years later with Blink.

nwienert 6y ago

The premise of React isn’t at all about performance optimization, it’s about components.

la_fayette 6y ago
Yes true, but why should one favor react over e.g. web-components if it is so much slower?
- acemarke 6y ago
  React and web components are different tools trying to solve different problems. Web components are primarily about trying to add new virtual HTML tags to "extend the platform". React and other frameworks are about trying to build interactive applications that require larger-scale UI management, efficiently, on top of the DOM, by defining pieces of that UI as a tree of reusable components (and using techniques that web components don't have available to them). If I want to add a color picker to an otherwise static HTML page, I might use a color picker web component. If I want to build a meaningful-sized app, I'd reach for React.
- kaoD 6y ago
  Web components are not built declaratively.
  - la_fayette 6y ago
    This declarative narrative is more or less a marketing gag, isn't it? Mixing Logic and Markup has always been an antipattern in web development. However, react calls this declarative and this is the new black now?
    - ricksharp 6y ago
      I’ve been doing web since 1990s and I‘ve always thought spreading a UI element across 3 separate files (often in different locations) was an anti-pattern (or 5+ files In 5 different folders if you want MVC). React is awesome because it allows feature-aligned separation of concerns (each component has a single job - render everything about a specific element - which is usually a well defined part of a specific use case). Jsx is the best UI system ever in terms of productivity - speaking from experience: I’ve implemented production apps using dozens of UI frameworks/platforms - Html, WYSIWYG, Flash, WindowsForms, WebForms, Ajax, Asp.Net Mvc, Razor, WPF, Xaml, Silverlight, Knockout, Handlebars, PhoneGap, Ionic, Bootstrap, MaterialUI, Angular2, React w/ Class Components, React w/ Mobx, React w/ Hooks I can tell you pros/cons of each of those. But at the end of the day I can develop an entire app in days in React+Hooks which would take me weeks in most any other.

lhorie 6y ago

> the whole premise for React (the virtual DOM) is based on outdated performance advice. Chrome has used a dirty-bit This mentality sorta falls into the exact pitfall GP mentioned (i.e. what you really want is for IE/Edge to be significantly faster bringing speed gains for everyone else along the way, not for Chrome to be microscopically faster at the expense of every other browser) There are real and significant costs in things like random access of .childNodes or bottom-up DOM construction in some browsers. At the height of the whole virtual dom thing, there was a lot of super browser-specific micro-optimizations going on, a lot of it w/ a heavy focus on Chrome, with IRHydra and stuff. It got a bit ridiculous when I figured out that you could make a significant dent in one of the popular benchmarks at the time not by tweaking JS anymore, but by removing unused CSS rules from bootstrap.css... But as you said, engines change quickly and I'm not sure it's really worth to be chasing micro-optimizations anymore. We're getting to a stage where the only way to get faster is to simply run less code. Some frameworks are getting the idea (svelte, marko).

nostrademons 6y ago
Or build better APIs into the browser and optimize them in the C++. IMHO that's the best long-term solution. Moves glacially slow, though, since there's a large engineering cost that needs the coordination of each major browser vendor. I was a big fan of Polymer/WebComponents in 2014, but they kinda dropped the ball. In hindsight I wish they'd just implemented the React API directly in the browser. (Though depending on how Google vs. Oracle goes in the Supreme Court, maybe that'll become illegal, sigh.)
- lhorie 6y ago
  This worked amazingly well for querySelector (vs jQuery's sizzle and friends at the time), but IIRC, JIT is so good now that there are APIs written in JS _because it's faster to do so than to use AOT_. I recall reading somewhere that the cost of jumping between JS and C++ land was a source of slowdowns with the DOM API, so there's that too. But overall, I agree with the idea of incorporating the ideas that are working into the platform. There have been various discussion over the years about how virtual dom could work as a native browser API, but unfortunately, the needle hasn't moved there at all.

om2 6y ago

All browsers have used a dirty bit for layout for at least the past 2 decades (source: I have worked on browser engines for 2 decades). This is not some new Chrome thing. And all browsers continue to have that same hazard that querying layout-dependent properties forces a synchronous style recalc and layout. The benefit of React (if any; it has a lot more overhead than vanilla JS+DOM) is that you can't hit that specific pitfall of forcing layout interspersed with DOM or style manipulation.

twsted 6y ago
> And all browsers continue to have that same hazard that querying layout-dependent properties forces a synchronous style recalc and layout. Could you explain why? Is the following true even when the parent is already in the DOM? parent.appendChild(document.createElement('div')); // Fast; ~50 us let w = parent.innerWidth; // Slow, forces reflow; ~20 ms
- om2 6y ago
  This is a slightly weird example because it's adding an empty <div>, so you can imagine it could be optimized if it provably has no effect on layout. But let's imagine instead that the node added to parent was a div with a text child. Or, slightly less obviously, the div is getting added in a document with a style rule of `div { width: 1000px;} In that case, the width could change. So the browser engine's options are: 1. Return a stale value from parent.innerWidth for now, and just lazily update style at the next event loop iteration. 2. Synchronously update style and layout (note, this update is not as expensive as a from-scratch layout), and return the up-to-date value of parent.innerWidth It turns out that, historically, the earliest browsers with scripting did option (2), and websites came to depend on it. So browsers had to keep on doing it, and so forth. Many folks in the web standards world would like to find away out of this dilemma, where DOM mutation doesn't risk this kind of performance hazard. You could also imagine an extra bad option: 3. Every time the DOM (or the CSSOM) is mutated, synchronously update layout. This is super expensive in the face of repeated DOM mutations. Repeated DOM mutations (e.g. adding multiple elements, setting multiple attributes) are way more common than repeatedly getting style/layout-dependent attributes. (3) has the same observable functional behavior as (2), but it's a lot slower, because it will do a lot of unnecessary layouts. I'm not totally sure if this explains everything you were wondering about, but I hope it helps some.