Chrome V8 version 8.0 — V8, — What to expect?

The most anticipated chrome release V8, hits its long-awaited v8.0 and will be shipping with chrome 80 release in February.

The v8.0 release with some new features — optional chaining, Nullish coalescing , faster higher-order builtins and 40% less memory use thanks to pointer compression, these features and changes will improve the performance and code productivity.

Let’s see them one by one —

Optional chaining ( ?.)

When accessing the nested object properties we need to do a manual check for properties existence i.e if they are nullish ( null or undefined ) or not.

// Error prone-version, could throw.
const nameLength = db.user.name.length;TypeError: Cannot read property 'length' of undefined, if user is nullish

If they are nullish and we try to access it, JavaScript would throw an error TypeError: Cannot read property 'property name' of undefined .

In many cases where an object is heavily nested, the if condition or ternary operator check becomes verbose and has the unwanted consequence of all truthy values instead of only non-nullish values like below —

// Less error-prone, but harder to read.let nameLength;
if (db && db.user && db.user.name)
  nameLength = db.user.name.length;// ORnameLength =
  (db
    ? (db.user
      ? (db.user.name
        ? db.user.name.length
        : undefined)
      : undefined)
    : undefined);

Optional chaining ( ?. ) help us with the above issue.

It helps us write less code and get a robust chain of property accesses that are easy to read and check if intermediate values are nullish. If it is then entire expression evaluates to undefined .

const nameLength = db?.user?.name?.length;

We can use optional chaining in the following 3 forms.

object?.property
object?.[expression]

const array = null;
array?.[0]; // => undefined

3. object?.([arg1, [arg2, ...]]) — executes an object method

const object = null;
object?.method('Some value'); // => undefined

These forms can be combined to create a long optional chain if you need it:

const value = object.maybeUndefinedProp?.maybeNull()?.[propName];

Nullish coalescing (??)

It’s a new short circuit operator meant to handle default values.

Currently, default values are sometimes handled with the logical || for falsy values and && operator for truthy, such as in the following example.

function test(props) {
  const res = props.isTrue || true; 
  // return true if props.isTrue is set to false also, 
  // whereas the required result should be the value of props.isTrue
 }

With the nullish coalescing operator, a ?? b evaluates to b when a is nullish ( null or undefined ), and otherwise evaluates to a .

So in the above case —

function test(props) {
  const res = props.isTrue ?? true;
  // return true only when props.isTrue is nullish or true
  // In case of false it evalutes to false
}

The nullish coalescing operator and optional chaining are companion features and work well together. The example may be further amended to handle the case when no props argument is passed in.

function test(props) {
  const enable = props?.isTrue ?? true;
  // …
}

Faster higher-order builtins

To understand the above performance optimization, we should know about TurboFan in V8. So let’s quickly see what it is.

TurboFan is a JIT compiler architect as a multi-layered translation and optimization pipeline in V8 that translates and optimizes the code to progressively lower forms until a better quality machine code is generated. It uses a concept called the sea of node .

const charCodeAt = Function.prototype.
 apply
 .bind(String.prototype.charCodeAt);// before
charCodeAt(string, 8); // a lot slower
string.charCodeAt(8); // a lot faster// After optimization - same performance
charCodeAt(string, 8);
string.charCodeAt(8);

Till now, the call to charCodeAt was completely opaque to TurboFan, which led to the generation of a generic call to a user-defined function.

With this new change, we are now able to recognize the calling of built-in String.prototype.charCodeAt function and are thus able to trigger all the further optimizations that TurboFan has in stock to improve calls to builtins, which leads to the same performance as the direct usage of builtin.

Pointer compression

The awesome V8 team, upon inspection of the heap, discovered that the tagged values (which represent pointers or small integers) occupy the majority of the heap!

Upon further inspection, they found that the tagged values are as big as the system pointer: they are 32 bits wide for 32-bit architectures, and 64 bits in 64-bit architectures. Then, when comparing the 32-bit version with the 64-bit one, we are using twice as much heap memory for every tagged value.

So, to solve above they stored only the unique lower bits into the heap and then use them to generate top bits for 64 bits architectures thus saving precious memory resources.

The above solution improved the performance on real websites in the time spent in V8, and in its garbage collector!

So, we can expect an overall speed improvement and some cool javascript feature with this v8 v8 releasee.

To read more about v8 — https://v8.dev/docs