React — одна из самых популярных библиотек для создания пользовательских интерфейсов. Однако при работе с большими объемами данных или сложными вычислениями разработчики часто сталкиваются с проблемой производительности. В этой статье мы рассмотрим концепцию React Lanes — механизм, который позволяет приоритизировать задачи рендеринга и сделать интерфейс более отзывчивым даже при выполнении тяжелых операций.

Что такое React Lanes?

Давайте рассмотрим типовую задачу для React. Пусть это будет тривиальный поиск по текстовым элементам. Для этого возьмем обычное поле ввода и список элементов, который фильтруется в зависимости от введенного значения в это поле.

const SearchList = ({ items, filter }) => {
  // Heavy filtering operation (simulation)
  const filteredItems = items.filter((item) =>
    item.toLowerCase().includes(filter.toLowerCase()),
  );

  return (
    <ul>
      {filteredItems.map((item, i) => (
        <li key={i}>{item}</li>
      ))}
    </ul>
  );
};

const App = () => {
  const [inputValue, setInputValue] = useState("");

  // Generate large list for demonstration
  const bigList = Array(10_000)
    .fill(null)
    .map((_, i) => `Item ${i + 1}`);

  const handleChange = (e) => {
    setInputValue(e.target.value);
  };

  return (
    <div>
      <input
        type="text"
        value={inputValue}
        onChange={handleChange}
        placeholder="Search..."
      />

      <SearchList items={bigList} filter={inputValue} />
    </div>
  );
}

Для наглядности, пусть список будет состоять из большого числа элементов. Что, очевидно, будет провоцировать тяжелую операцию фильтрации массива. Получившееся приложение можно потрогать руками ниже.

С количеством элементов можно поэкспериментировать в зависимости от мощности устройства и среды, где исполняется приложение. Но так или иначе, если быстро вводить значение в строку поиска, можно заметить некоторый лаг, когда в выборке оказывается много элементов.

Происходит это из-за того, что каждое изменение значения приводит к ререндеру компонента SearchList, который в свою очередь должен отрисовать необходимое количество дочерних элементов.

Синхронные обновления

Пример выше демонстрирует типичную синхронную работу по обновлению дерева компонентов. Подробно о процессе обновления я писал в статье Детальный React. Реконсиляция, рендеры, Fiber, виртуальное дерево. Движок Fiber пытается выполнить все необходимые изменения за один раз. Другими словами, фаза render не завершится, пока реконсилер не переберет всё запланированные синхронные изменения.

Конкретно в нашем примере, каждое изменение текстового поля вызывает реконсиляцию SearchList, а он в свою очередь ставит рендеры дочерних компонентов в той же фазе. И пока все дочерние ноды не будут обработаны, основной поток будет заблокирован работой движка. Если выводимых компонентов слишком много, время блокировки становится существенным и проявляется в виде задержки отклика на пользовательский ввод.

На скриншоте выше в текстовое поле был введен символ 0, что дает 2620 дочерних элементов. Реконсиляция такого количества элементов заняла 253ms, учитывая, что задержки более 100ms считаются заметными человеческому глазу, а расчетное время браузерного фрейма 16.6ms (при частоте обновления 60 fps).

При добавлении еще одного "0" выводится 181 элемент. Реконсиляция заняла уже 146ms. Однако, это всё равно много.

Продолжим вводить нули. Следующий "0" даст только 10 элементов и тут мы видим уже приемлемую продолжительность в 10.6ms

Четвертый ноль оставит только один единственный элемент и продолжительность задачи составила всего 2ms.

Что не на много больше, чем при значения "00000", при котором нет ни одного выводимого элемента.

Теперь проделаем обратную процедуру и будем удалять по одному символу из текстового поля.

Значение "0000". Продолжительность 0.9ms.

Значение "000". Продолжительность 1.2ms.

Значение "00". Продолжительность 12.8ms.

Значение "0". Продолжительность 178ms.

И наконец, пустая строка. Продолжительность 699ms.

Приоритеты задач

Проблема, как говорится, налицо. Блокирующие операции довольно долго оставались проблемой, с которой надо было что-то делать. В качестве решения можно было бы предложить разделить тяжелые операции на потоки и выполнить их параллельно. Но JavaScript-задача не может выполняться в нескольких потоках.

ReactPriorityLevel

Первые попытки решить проблему были предприняты в 2016-м. В версии 15.2.1 было впервые введено понятие ReactPriorityLevel. Раз нельзя разделить задачи на параллельные потоки, можно хотя бы расставить их в порядке важности. Суть ReactPriorityLevel в том, чтобы проставить флаг приоритета каждому обновлению дерева.

Изначально таких приоритетов было 5, от наиболее важного к менее важному:

• SynchronousPriority - для контролируемого обновления инпутов и синхронных операций
• AnimationPriority - анимации должны завершать расчет очередного шага в текущем фрейме
• HighPriority - обновления, которые должны быть выполнены как можно быстрее для сохранения оптимального отклика
• LowPriority - для запросов и получения ответа из хранилищ
• OffscreenPriority - для элементов, которые были скрыты на странице, но снова становятся видимыми

Expiration Times

В целом, концепция приоритетов дала определенный результат. Но не все проблемы были решены. ReactPriorityLevel разделял задачи по группам, но внутри группы задачи по-прежнему имеют одинаковый приоритет. Например, на странице вполне может оказаться несколько анимируемых элементов. В конце 2017-го была представлена версия React 16.1, в которой вместо флагов приоритетов предлагалось выставлять время, до которого задача должна быть обработана. Чем важнее задача, тем меньший expirationTime она имела и, соответственно, бралась в работу раньше остальных.

Lanes

Концепция Expiration Times оказалась вполне рабочей. React 16 жил с ней следующие 3 года. Суть модели заключалась в том, что имея приоритеты A > B > C, нельзя взять в работу B, не выполнив при этом A. Аналогично, нельзя работать над C, не взяв в работу A и B.

Такой подход хорошо себя показывал вплоть до того, пока не появился Suspense. Приоритизация работает покуда все задачи выполняются линейно. Когда в процесс вмешивается отложенная задача (такая, как Suspense), появляется ситуация, когда отложенная задача с высоким приоритетом блокирует менее приоритетные основные.

В плане выражения группы сразу из нескольких приоритетов, модель Expiration Times довольно ограничена. Чтобы понять, включать ли задачу в объем работ на текущей итерации, достаточно сравнить относительные приоритеты:

const isTaskIncludedInBatch = priorityOfTask >= priorityOfBatch;

Чтобы решить проблему Suspense, можно было бы использовать Set с приоритетами. Но это было бы очень накладно с точки зрения производительности и свело бы на нет все преимущества приоритетизации.

В качестве компромисса можно было бы ввести диапазоны приоритетов примерно следующим образом:

const isTaskIncludedInBatch = taskPriority <= highestPriorityInRange && taskPriority >= lowestPriorityInRange;

Но даже если закрыть глаза на то, что в таком случае потребуется держать два поля, этот подход всё равно не решает всех проблем. К примеру, как удалить задачу в середине диапазона? Какое-то решение конечно можно придумать. Но как бы то ни было, любые манипуляции с диапазонами будут неизбежно влиять на другие группы и их поддержка и стабильность превротяться в настоящий кошмар.

Чтобы избежать всех этих проблем, разработчики React решили разделить две концепции приоретизации и группировки. И предложили выражать группы задач относительными числами, представляющими собой битовую маску.

const isTaskIncludedInBatch = (task & batchOfTasks) !== 0;

Тип битовой маски представляющий задачу, называется Lane. А битовая маска представляющая группу задач - Lanes.

Как работают Lanes

В официальном релизе Lanes впервые появились в октябре 2020 с версии React 17.0.0. Это был довольно большой рефакторинг, который существенно повлиял на работу Fiber.

На данный момент последняя стабильная версия React v19.0.0. Большая часть работы Lanes инкапсулирована в модуле ReactFiberLane реконсилятора.

Фактически, Lane является 32-битным числом, где каждый бит указывает на принадлежность задачи к какой-либо из полос.

/packages/react-reconciler/src/ReactFiberLane.js#L39

export const TotalLanes = 31;

export const NoLanes: Lanes = /*                        */ 0b0000000000000000000000000000000;
export const NoLane: Lane = /*                          */ 0b0000000000000000000000000000000;

export const SyncHydrationLane: Lane = /*               */ 0b0000000000000000000000000000001;
export const SyncLane: Lane = /*                        */ 0b0000000000000000000000000000010;
export const SyncLaneIndex: number = 1;

export const InputContinuousHydrationLane: Lane = /*    */ 0b0000000000000000000000000000100;
export const InputContinuousLane: Lane = /*             */ 0b0000000000000000000000000001000;

export const DefaultHydrationLane: Lane = /*            */ 0b0000000000000000000000000010000;
export const DefaultLane: Lane = /*                     */ 0b0000000000000000000000000100000;

export const SyncUpdateLanes: Lane =
  SyncLane | InputContinuousLane | DefaultLane;
  
const TransitionHydrationLane: Lane = /*                */ 0b0000000000000000000000001000000;
const TransitionLanes: Lanes = /*                       */ 0b0000000001111111111111110000000;
const TransitionLane1: Lane = /*                        */ 0b0000000000000000000000010000000;
const TransitionLane2: Lane = /*                        */ 0b0000000000000000000000100000000;
const TransitionLane3: Lane = /*                        */ 0b0000000000000000000001000000000;
const TransitionLane4: Lane = /*                        */ 0b0000000000000000000010000000000;
const TransitionLane5: Lane = /*                        */ 0b0000000000000000000100000000000;
const TransitionLane6: Lane = /*                        */ 0b0000000000000000001000000000000;
const TransitionLane7: Lane = /*                        */ 0b0000000000000000010000000000000;
const TransitionLane8: Lane = /*                        */ 0b0000000000000000100000000000000;
const TransitionLane9: Lane = /*                        */ 0b0000000000000001000000000000000;
const TransitionLane10: Lane = /*                       */ 0b0000000000000010000000000000000;
const TransitionLane11: Lane = /*                       */ 0b0000000000000100000000000000000;
const TransitionLane12: Lane = /*                       */ 0b0000000000001000000000000000000;
const TransitionLane13: Lane = /*                       */ 0b0000000000010000000000000000000;
const TransitionLane14: Lane = /*                       */ 0b0000000000100000000000000000000;
const TransitionLane15: Lane = /*                       */ 0b0000000001000000000000000000000;

const RetryLanes: Lanes = /*                            */ 0b0000011110000000000000000000000;
const RetryLane1: Lane = /*                             */ 0b0000000010000000000000000000000;
const RetryLane2: Lane = /*                             */ 0b0000000100000000000000000000000;
const RetryLane3: Lane = /*                             */ 0b0000001000000000000000000000000;
const RetryLane4: Lane = /*                             */ 0b0000010000000000000000000000000;

export const SomeRetryLane: Lane = RetryLane1;

export const SelectiveHydrationLane: Lane = /*          */ 0b0000100000000000000000000000000;

const NonIdleLanes: Lanes = /*                          */ 0b0000111111111111111111111111111;

export const IdleHydrationLane: Lane = /*               */ 0b0001000000000000000000000000000;
export const IdleLane: Lane = /*                        */ 0b0010000000000000000000000000000;

export const OffscreenLane: Lane = /*                   */ 0b0100000000000000000000000000000;
export const DeferredLane: Lane = /*                    */ 0b1000000000000000000000000000000;

Условно, все полосы можно разделить на синхронные и отложенные.

Синхронные полосы

К синхронным полосам относятся SyncLane, InputContinuousLane и DefaultLane. Задачи, поставленные в эти полосы имеют наивысший приоритет и выполняются синхронно в текущей фазе реконсилятора.

Исходя из названий можно предположить, что разные типы задач могут иметь разный приоритет даже в синхронной фазе. Cамыми приоритетными считаются:

• Размонтирование рута, что приводит к немедленной очистке стейта React и инициирует асинхронное удаление элементов дерева
• Hot Reload, т.к. JS модули должны быть немедленно заменены на новые
• Любые оверрайды в Dev Tools всегда должны происходить в первую очередь
• Хук useSyncExternalStore синхронно читает данные из внешнего хранилища, это должно происходить в самом начале реконсиляции файбера
• Хук useOptimistic гарантирует синхронное обновление оптимистичного стейта
• В текущей версии React официально пока еще нет компонента <Activity /> (ранее носил название <Offscreen />), но в движке он присутствует и когда-нибудь в будущем станет доступным. Этот компонент имеет три режима: "hidden", "visible" и "manual". В отличие от первых двух, режим manual предполагает, что разработчик сам отвечает за скрытие/показ компонента и вручную вызывает Activity.attach() и Activity.detach(). Эти два метода так же выполняются синхронно, чтобы React мог немедленно поставить в очередь работу по монтированию/размонтированию компонента.

Все выше перечисленные процессы происходят в полосе SyncLane.

Приоритеты событий

Неотъемлемым диспатчером реакций в React являются события. Точнее, синтетические события. И среди всего множества потенциальных событий есть более приоритетные и менее приоритетные. Поэтому React разделяет их все на три условных группы:

• Дискретные - события, вызванные напрямую пользователем (например, MouseEvent или KeyboardEvent) и при этом все события в последовательности - намеренные, например "click". Таким событиям присваивается приоритет DiscreteEventPriority и они выполнятся в SyncLane. Эти события могут прерывать фоновые задачи, но не могут быть сгруппированы на временной дистанции (каждое событие происходит здесь и сейчас).

import { useState } from "react";
import { createRoot } from "react-dom/client";

function App() {
  const [count, setCount] = useState(0);
  const handleClick = () => {
    setCount(count + 1);
  };
  return <button onClick={handleClick}>Update state in the SyncLane</button>;
}

const root = createRoot(document.getElementById("root"));
root.render(<App />);

На данный момент список дискретных событий выглядит так:

beforetoggle
cancel
click
close
contextmenu
copy
cut
auxclick
dblclick
dragend
dragstart
drop
focusin
focusout
input
invalid
keydown
keypress
keyup
mousedown
mouseup
paste
pause
play
pointercancel
pointerdown
pointerup
ratechange
reset
resize
seeked
submit
toggle
touchcancel
touchend
touchstart
volumechange
change
selectionchange
textInput
compositionstart
compositionend
compositionupdate
beforeblur
afterblur
beforeinput
blur
fullscreenchange
focus
hashchange
popstate
select
selectstart

• Продолжительные - события, вызванные напрямую пользователем, но пользователь не может различить отдельные события в последовательности (например, mouseover). Таким событиям присваивается приоритет ContinuousEventPriority и они выполняются в InputContinuousLane. Эти события могут прерывать фоновые задачи и могут быть сгруппированы на протяжении времени.

import { useState } from "react";
import { createRoot } from "react-dom/client";

function App() {
  const [count, setCount] = useState(0);
  const handleMouseOver = () => setCount(count + 1);

  return (
    <div onMouseOver={handleMouseOver}>
      Update state in the InputContinuousLane
    </div>
  );
}

const root = createRoot(document.getElementById("root"));
root.render(<App />);

Список продолжительных событий:

drag
dragenter
dragexit
dragleave
dragover
mousemove
mouseout
mouseover
pointermove
pointerout
pointerover
scroll
touchmove
wheel
mouseenter
mouseleave
pointerenter
pointerleave

• Остальные - события, которые не попадают в первые две группы (кроме message, у них приоритет определяется динамически в зависимости от текущего приоритета планировщика). Таким событиям присваивается приоритет DefaultEventPriority и они выполняются в DefaultLane соответственно. Отсутствие события так же считается DefaultEventPriority.

import { createRoot } from "react-dom/client";

const root = createRoot(document.getElementById("root"));

root.render(
  <div>
    No events emitted. Common rendering uses the DefaultLane
  </div>
);

Отложенные полосы

Отложенные полосы, как не трудно догадаться из названия, могут выполняться асинхронно с задержкой. Они имеют более низкий приоритет по сравнению с синхронными полосами и выполняются в фоне после того, как все синхронные полосы были отработаны. Задачи, выполняемые в отложенных полосах считаются неблокирующими.

TransitionLane

Пожалуй самый очевидный способ поставить отложенную задачу - через startTransition.

import { startTransition, useEffect, useState } from "react";
import { createRoot } from "react-dom/client";

function App() {
  const [, setHigh] = useState(0);
  const [, setLow] = useState(0);
  
  useEffect(() => {
    startTransition(() => {
      // 2. TransitionLane will be proceeded in a background after a sync lane
      setLow((prevLow) => prevLow + 1);
    });
    
    // 1. DefaultLane will be done first
    setHigh((prevHigh) => prevHigh + 1);
  }, []);
  
  return null;
}

const root = createRoot(document.getElementById("root"));
root.render(<App />);

Задачи, которые ставятся в TransitionLane, могут параллелиться. Для этого предусмотрено целых 15 полос TransitionLane1..15. В отличие от синхронных полос, где параллелизм большого смысла не имеет, их эффективнее объединять в пакеты, чем параллелить.

import { startTransition, useEffect, useState } from "react";
import { createRoot } from "react-dom/client";

function App() {
  const [, setHigh] = useState(0);
  const [, setLow] = useState(0);
  
  useEffect(() => {
    // TransitionLane1
    startTransition(() => {
      setLow((prevLow) => prevLow + 1);
    });

    // TransitionLane2
    setTimeout(() => {
      startTransition(() => {
        setLow((prevLow) => prevLow + 1);
      });
    }, 0);

    // TransitionLane3
    setTimeout(() => {
      startTransition(() => {
        setLow((prevLow) => prevLow + 1);
      });
    }, 0);
    
    // DefaultLane
    setHigh((prevHigh) => prevHigh + 1);
  }, []);
  
  return null;
}

const root = createRoot(document.getElementById("root"));
root.render(<App />);

RetryLane

Ещё один способ выполнить отложенную задачу - Suspense.

import { Suspense, use } from "react";
import { createRoot } from "react-dom/client";

const cache = new Map();

function fetchData() {
  if (!cache.has("data")) {
    cache.set("data", getData());
  }
  return cache.get("data");
}

async function getData() {
  // Add a fake delay to make waiting noticeable.
  await new Promise((resolve) => {
    setTimeout(resolve, 1_000);
  });
  
  return ["item1", "item2", "item3"];
}

function AsyncComponent() {
  const items = use(fetchData());
  
  return (
    <ul>
      {items.map((item) => (
        <li key={item}>{item}</li>
      ))}
    </ul>
  );
}

function App() {
  return (
    <>
      <h1>Retry lanes</h1>
      <Suspense fallback="Loading...">
        <AsyncComponent />
      </Suspense>
    </>
  );
}

const root = createRoot(document.getElementById("root"));
root.render(<App />);

Говоря простым языком, Suspense рендерит сначала fallback компонент. Далее, когда один или несколько промисов внутри Suspended компонента зарезолвятся, Fiber попытается повторить рендеринг, поставив задачу в RetryLane. Как и TransitionLane, RetryLane может параллелиться и имеет четыре полосы RetryLane1..4.

function AsyncComponent() {
  const items = use(fetchData());
  const meta = use(fetchMeta());
  
  return (
    <ul>
      {items.map((item) => (
        <li key={items}>{item}</li>
      ))}
    </ul>
  );
}

function App() {
  return (
    <>
      <h1>Retry lanes</h1>
      <Suspense fallback="Loading...">
        <AsyncComponent />
      </Suspense>
    </>
  );
}

const root = createRoot(document.getElementById("root"));
root.render(<App />);

Аналогичная работа происходит и с компонентами SuspenseList и Activity. Но они пока не включены в последний, на сегодняшний день релиз React. Поэтому рассматривать их подробно сейчас не имеет смысла.

IdleLane

Следующая по приоритету полоса - IdleLane. Идея IdleLane заключается в том, чтобы некоторые задачи выполнять только тогда, когда движок простаивает и не занят другими, более важными задачами. Это можно сравнить с Idle-периодом в браузерном планировщике (я писал про это подробнее в статье Chromium. Отрисовка страницы с помощью Blink, CC и планировщика), только на уровне движка Fiber и React-планировщика.

На данный момент нет ни React DOM API, которые могли бы вызвать обновление с idle-приоритетом, ни нативных DOM событий с idle-приоритетом. Поэтому пока этой полосой можно воспользоваться только через внутренние методы движка, не доступные в prod-сборке React.

OffscreenLane

Чуть выше, когда я писал про синхронные полосы, я уже упоминал так называемый компонент Offscreen, который теперь носит название Activity. Его идея заключается в том, чтобы определять, находится ли компонент в данный момент в видимой части страницы, или за её пределами. Если компонент сейчас не виден на экране, то и задачи его имеют низкий приоритет. Собственно, для таких задач и была выделена полоса OffscreenLane.

К сожалению, это еще один компонент, который пока не вошел в текущий релиз React. Но у него есть все шансы попасть в один из следующих. Будем надеяться, что в обозримом будущем мы его таки увидим.

DeferredLane

Не трудно догадаться, что полоса DeferredLane предназначена для хука useDeferredValue. Однако, с ней не всё так просто, как может показаться.

import { useDeferredValue } from "react";
import { createRoot } from "react-dom/client";

function App() {
  const text = useDeferredValue("Final");
  
  return <div>{text}</div>;
}

const root = createRoot(document.getElementById("root"));
root.render(<App />);

Если у хука не указан второй аргумент - initialValue, ему не с чем будет сравнивать новое значение при монтировании и он выполнится синхронно в DefaultLane. Однако, если у хука имеется предыдущее значение, с которым он может сравнить текущее, например когда хук смонтирован и обновляется повторно или если указать initialValue, мы увидим следующую картину.

import { useDeferredValue } from "react";
import { createRoot } from "react-dom/client";

function App() {
  const text = useDeferredValue("Final", "Initial");
  
  return <div>{text}</div>;
}

const root = createRoot(document.getElementById("root"));
root.render(<App />);

Работа по факту была выполнена в TransitionLane. Если бы мы попробовали выполнить хук в Offscreen компоненте, то увидели бы, что он выполнен в OffscreenLane. Дело в том, что DeferredLane является промежуточной технической полосой. Она служит только для логического отделения отложенных задач от остальных. Собственного приоритета выполнения эта задача не имеет и всегда подмешивается к другим полосам исходя из ситуации.

Неблокирующий рендеринг

Давайте теперь вернемся к нашему исходному примеру и попробуем избавиться от блокировок интерфейса тяжелыми операциями.

const SearchList = ({ items, filter }) => {
  // Heavy filtering operation (simulation)
  const filteredItems = items.filter((item) =>
    item.toLowerCase().includes(filter.toLowerCase()),
  );

  return (
    <ul>
      {filteredItems.map((item, i) => (
        <li key={i}>{item}</li>
      ))}
    </ul>
  );
};

const App = () => {
  const [inputValue, setInputValue] = useState("");
  const deferredValue = useDeferredValue(inputValue);
  
  // Generate large list for demonstration
  const bigList = Array(10_000)
    .fill(null)
    .map((_, i) => `Item ${i + 1}`);

  const handleChange = (e) => {
    setInputValue(e.target.value);
  };

  return (
    <div>
      <input
        type="text"
        value={inputValue}
        onChange={handleChange}
        placeholder="Search..."
      />

      <SearchList items={bigList} filter={deferredValue} />
    </div>
  );
}

Всё, что мы сделали, в SearchList стали передавать deferredValue вместо inputValue. Это позволило нам поставить задачу по расчету массива элементов в отложенных TransitionLane и разблокировать синхронные обновления элемента input.

Конечно, чудес от React ждать не стоит. Тяжелая операция по-прежнему остается тяжелой. А React, будучи просто JavaScript-библиотекой, по-прежнему выполняется в основном потоке браузера. Система Lanes по своей сути является лишь способом приоритизации задач. Более важные задачи выполняются в первую очередь, менее важные - откладываются на потом. Однако, если тяжелая отложенная задача взята в работу, она всё равно будет блокировать основной поток.

Практические рекомендации по использованию Lanes

Понимание системы Lanes в React может существенно помочь в оптимизации производительности приложений. Вот несколько практических рекомендаций:

1. Используйте useDeferredValue для тяжелых операций рендеринга. Как мы видели в примере с поиском, отложенное значение позволяет сохранить отзывчивость интерфейса даже при работе с большими объемами данных.
2. Применяйте startTransition для неприоритетных обновлений UI. Когда вам нужно выполнить обновление, которое не требует мгновенной реакции (например, переключение вкладок или загрузка дополнительного контента), оборачивайте его в startTransition.
3. Разделяйте синхронные и асинхронные части вашего приложения. Элементы, требующие немедленной реакции (поля ввода, кнопки), должны обновляться синхронно, а тяжелые вычисления и отображение больших списков лучше отложить.
4. Используйте Suspense для асинхронной загрузки данных. Это позволит React автоматически управлять приоритетами задач при загрузке данных с сервера.
5. Помните о вложенности компонентов. Чем глубже вложен компонент, тем больше времени может занять его обновление. Старайтесь выносить тяжелые компоненты ближе к корню дерева.

Будущее React Lanes

Система Lanes продолжает развиваться. В будущих версиях React мы можем ожидать:

• Появление официального API для компонента Activity, который позволит более гибко управлять приоритетами рендеринга в зависимости от видимости компонентов.
• Возможное внедрение поддержки Web Workers для выполнения тяжелых вычислений в отдельных потоках.
• Дальнейшее развитие API для более тонкой настройки приоритетов задач.
• Улучшение интеграции с инструментами профилирования для более наглядного отображения работы системы приоритетов.

Заключение

Система Lanes в React представляет собой мощный инструмент для оптимизации пользовательского опыта. Она не делает ваше приложение быстрее в абсолютном смысле, но позволяет более разумно распределять вычислительные ресурсы, отдавая приоритет тому, что важно для пользователя прямо сейчас.

Правильное использование useDeferredValue, startTransition и Suspense может значительно улучшить воспринимаемую производительность вашего приложения, делая его более отзывчивым даже при выполнении сложных операций. Это особенно важно для современных веб-приложений, которые часто работают с большими объемами данных и сложными интерфейсами.

В конечном счете, понимание внутреннего устройства React и принципов работы системы приоритетов позволяет разработчикам создавать более эффективные и дружелюбные к пользователю приложения, что является ключевой целью любой фронтенд-разработки.

Мои телеграмм-каналы:

English version: https://blog.frontend-almanac.com/react-lanes

Начнем с того, что немного освежим мат. часть. Мы знаем, что стили описываются с помощью языка CSS. Получив строковое описание стилей на языке CSS, браузер разбирает его и составляет объект CSSOM. Интерфейс этого объекта представлен спецификацией https://www.w3.org/TR/cssom-1. Он следует принципам каскадности и наследования, изложенным в https://www.w3.org/TR/css-cascade-4.

Из выше указанных спецификаций мы знаем, что основной единицей CSS является "свойство". Свойству присваивается значение, характерное конкретно этому свойству. Если значение не задано явным образом, оно наследуется от выше стоящего стиля или, если нет вышестоящего, будет установлено initial value.

Набор свойств для элемента собирается в правила CSSRule. Правила бывают разных типов. Наиболее популярный тип - CSSStyleRule, определяющий свойства элемента. Такое правило начинается с указания одного из валидных селекторов и последующих фигурных скобок с набором свойств и значений <selector>: { ... } Имеются и другие типы правил, например CSSFontFaceRule, описывающий параметры подключаемого шрифта @font-face { ... }, CSSMediaRule - @media { ... } и др. Полный список в спецификации https://www.w3.org/TR/cssom-1/#css-rules.

Правила собираются в так называемый CSSStyleSheet, который фактически является абстрактным представлением тэга <style>. В свою очередь, style sheets собираются в коллекцию и привязываются к документу.

Все эти уровни абстракции и являются моделью CSS Object Model (CSSOM). И хотя спецификация описывает в основном только синтаксис модели, на практике в неё же входит и непосредственная реализация CSS API браузера. Такие функции, как computed style, методы кодировки цвета, математические операции и многое другое - тоже часть CSSOM.

Установка свойства в Blink

С теорией разобрались, теперь давайте немного заглянем под капот браузера. А точнее в движок рендеринга Blink, используемый браузерами Chromium, Opera, WebView и др. Blink является частью репозитория Сhromium и не поставляется самостоятельно. Поэтому эксперименты будем проводить именно в Chromium (версия 132.0.6812.1 на момент написания статьи).

style.setProperty

Начнем с метода style.setProperty.

element.style.setProperty("background-color", "red");

Чтобы понять, что происходит под капотом Blink, стоит заглянуть внутрь самого Blink.

/third_party/blink/renderer/core/css/abstract_property_set_css_style_declaration.cc#130

void AbstractPropertySetCSSStyleDeclaration::setProperty(
    const ExecutionContext* execution_context,
    const String& property_name,
    const String& value,
    const String& priority,
    ExceptionState& exception_state) {
  CSSPropertyID property_id =
      UnresolvedCSSPropertyID(execution_context, property_name);
  if (!IsValidCSSPropertyID(property_id) || !IsPropertyValid(property_id)) {
    return;
  }
  
  bool important = EqualIgnoringASCIICase(priority, "important");
  if (!important && !priority.empty()) {
    return;
  }
  
  const SecureContextMode mode = execution_context
                                     ? execution_context->GetSecureContextMode()
                                     : SecureContextMode::kInsecureContext;
  SetPropertyInternal(property_id, property_name, value, important, mode,
                      exception_state);
}

Первым делом проходит базовая проверка переданного свойства на валидность. Далее проверяется приоритет стиля и вызывается внутренний метод SetPropertyInternal.

/third_party/blink/renderer/core/css/abstract_property_set_css_style_declaration.cc#236

void AbstractPropertySetCSSStyleDeclaration::SetPropertyInternal(
    CSSPropertyID unresolved_property,
    const String& custom_property_name,
    StringView value,
    bool important,
    SecureContextMode secure_context_mode,
    ExceptionState&) {
  StyleAttributeMutationScope mutation_scope(this);
  WillMutate();
  
  MutableCSSPropertyValueSet::SetResult result;
  if (unresolved_property == CSSPropertyID::kVariable) {
    AtomicString atomic_name(custom_property_name);
    
    bool is_animation_tainted = IsKeyframeStyle();
    result = PropertySet().ParseAndSetCustomProperty(
        atomic_name, value, important, secure_context_mode, ContextStyleSheet(),
        is_animation_tainted);
  } else {
    result = PropertySet().ParseAndSetProperty(unresolved_property, value,
                                               important, secure_context_mode,
                                               ContextStyleSheet());
  }
  
  if (result == MutableCSSPropertyValueSet::kParseError ||
      result == MutableCSSPropertyValueSet::kUnchanged) {
    DidMutate(kNoChanges);
    return;
  }
  
  CSSPropertyID property_id = ResolveCSSPropertyID(unresolved_property);
  
  if (result == MutableCSSPropertyValueSet::kModifiedExisting &&
      CSSProperty::Get(property_id).SupportsIncrementalStyle()) {
    DidMutate(kIndependentPropertyChanged);
  } else {
    DidMutate(kPropertyChanged);
  }
  
  mutation_scope.EnqueueMutationRecord();
}

В этом внутреннем методе запускается процесс мутации, парсится строковое значение и устанавливается данному свойству. После чего изменения попадают в CSSOM. В целом, процесс не хитрый.

setAttribute

Теперь взглянем на setAttribute.

element.setAttribute("style", "background-color: red");

Данная операция выходит за рамки CSSOM и затрагивает элемент и его атрибуты, что ведет к изменения в DOM. В рамках DOM существует класс Attr, описывающий один атрибут элемента. Существует несколько способов установить значение атрибута.

/third_party/blink/renderer/core/dom/attr.cc#73

void Attr::setValue(const AtomicString& value,
                    ExceptionState& exception_state) {
  // Element::setAttribute will remove the attribute if value is null.
  DCHECK(!value.IsNull());
  if (element_) {
    element_->SetAttributeWithValidation(GetQualifiedName(), value,
                                         exception_state);
  } else {
    standalone_value_or_attached_local_name_ = value;
  }
}

Данный метод позволяет нам присваивать значение существующему атрибуту. Другими словами, мы можем сделать так.

element.style = "background-color: red";

Что приведет к вызову метода SetAttributeWithValidation, о котором поговорим чуть ниже.

В нашем же исходном случае мы не обращаемся к атрибуту style напрямую, а вызываем метод setAttribute из класса Element.

/third_party/blink/renderer/core/dom/element.h#282

void setAttribute(const QualifiedName& name, const AtomicString& value) {
  SetAttributeWithoutValidation(name, value);
}

Который обращается уже к другому методу SetAttributeWithoutValidation.

Итак, что же это за методы SetAttributeWithoutValidation и SetAttributeWithValidation?

/third_party/blink/renderer/core/dom/element.cc#10314

void Element::SetAttributeWithoutValidation(const QualifiedName& name,
                                            const AtomicString& value) {
  SynchronizeAttribute(name);
  SetAttributeInternal(FindAttributeIndex(name), name, value,
                       AttributeModificationReason::kDirectly);
}

void Element::SetAttributeWithValidation(const QualifiedName& name,
                                         const AtomicString& value,
                                         ExceptionState& exception_state) {
  SynchronizeAttribute(name);
  
  AtomicString trusted_value(TrustedTypesCheckFor(
      ExpectedTrustedTypeForAttribute(name), value, GetExecutionContext(),
      "Element", "setAttribute", exception_state));
  if (exception_state.HadException()) {
    return;
  }
  
  SetAttributeInternal(FindAttributeIndex(name), name, trusted_value,
                       AttributeModificationReason::kDirectly);
}

Как мы можем видеть, оба метода в сущности делают одно и то же. Сначала синхронизируют текущее актуальное значение атрибута, на случай если где-то есть незавершенная мутация. После чего уже непосредственно переходят к процессу установки нового значения. Разница лишь в том, что во втором случае перед установкой нового значения проводится его валидация на соответствие данному атрибуту. Другими словами, вот так не получится.

element.style = "invalid-prop: red"
// <div style></div>

Попытка присвоить атрибуту style невалидный стиль приведет к удалению значения в атрибуте.

Однако, нам ничто не помешает сделать вот так.

element.setAttribute("style", "invalid-prop: red")
// <div style="invalid-prop: red"></div>

В этом случае style будет установлен вне зависимости от того, что мы указали в качестве значения.

Выглядит довольно странно. Почему бы не валидировать значения атрибутов всегда? Ответ довольно простой. Метод setAttribute, это своего рода backdor для атрибутов. Он призван оперировать не только встроенными атрибутами, но и произвольными, такими как например, data-*.

element.setAttribute("data-ship-id", "324");
element.setAttribute("data-weapons", "laserI laserII");
element.setAttribute("data-shields", "72%");
element.setAttribute("data-x", "414354");
element.setAttribute("data-y", "85160");
element.setAttribute("data-z", "31940");
element.setAttribute("onclick", "spaceships[this.dataset.shipId].blasted()");

setAttribute работает на уровне DOM элемента и его задача просто присвоить значение атрибуту без каких либо валидаций. Подробный алгоритм описан в DOM стандарте.

Что быстрее?

На основании вышесказанного можно сделать предположение, что style.setProperty должен работать быстрее, так как в отличие от setAttribute движку не требуется искать ссылку на объект атрибута в таблице атрибутов и он может сразу приступить к установке значения. С другой стороны, расходы на валидацию самого значения могут оказаться существенными.

Испытание 1. Одно свойство

Чтобы определиться, что же все таки быстрее, проведем эксперимент. Для этого нам понадобится HTML-страница с тестовым элементом и парой кнопок.

<div id="test-element"></div>
<button onclick="handleSetProperty()">style.setProperty</button>
<button onclick="handleSetAttribute()">setAttribute</button>

И не сложный JS скрипт.

const N = 100;

function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

function createElement() {
  const el = document.getElementById("test-element");
  
  const newEl = document.createElement("div");
  newEl.setAttribute("id", "test-element");
  newEl.setAttribute("width", 100);
  newEl.setAttribute("height", 100);
  
  el.replaceWith(newEl);
  
  return newEl;
}

async function handleSetProperty() {
  const durations = [];

  for await (const i of new Array(N).fill(true).map((_, index) => index)) {
    const el = createElement();

    await sleep(300);

    const startTime = performance.now();
    el.style.setProperty("background-color", "red");
    const duration = performance.now() - startTime;

    durations.push(duration);

    await sleep(300);

    console.log(i);
  }

  console.log(durations);
}

async function handleSetAttribute() {
  const durations = [];

  for await (const i of new Array(N).fill(true).map((_, index) => index)) {
    const el = createElement();

    await sleep(300);

    const startTime = performance.now();
    el.setAttribute("style", "background-color: red");
    const duration = performance.now() - startTime;

    durations.push(duration);

    await sleep(300);

    console.log(i);
  }

  console.log(durations);
}

Данный скрипт по нажатию на одну из кнопок будет запускать цикл из 100 итераций по установке значения style тестовому элементу. Для чистоты эксперимента на каждой итерации будем создавать новый тестовый элемент и делать паузу после создания элемента и после установки значения, дабы исключить браузерные оптимизации и гарантировать отрисовку элемента после каждой итерации. Замеры будем делать отдельно, после жесткой перезагрузки страницы.

Собрав замеры ста итераций, вычислим простое среднее и получим следующий результат.

avgSetProperty     0.07400000274181366
avgSetAttribute    0.08999999761581420

В данном эксперименте уверенно лидирует style.setProperty. Однако, мы пытались устанавливать только одно единственное CSS-свойство.

Испытание 2. Два свойства

Для объективности, повторим эксперимент сразу с двумя свойствами. Для этого немного изменим тестовые функции.

async function handleSetProperty() {
  const durations = [];

  for await (const i of new Array(N).fill(true).map((_, index) => index)) {
    const el = createElement();

    await sleep(300);

    const startTime = performance.now();
    el.style.setProperty("background-color", "red");
    el.style.setProperty("border", "1px solid blue");
    const duration = performance.now() - startTime;

    durations.push(duration);

    await sleep(300);

    console.log(i);
  }

  console.log(durations);
}

async function handleSetAttribute() {
  const durations = [];

  for await (const i of new Array(N).fill(true).map((_, index) => index)) {
    const el = createElement();

    await sleep(300);

    const startTime = performance.now();
    el.setAttribute("style", "background-color: red; border: 1px solid blue;");
    const duration = performance.now() - startTime;

    durations.push(duration);

    await sleep(300);

    console.log(i);
  }

  console.log(durations);
}

Запустив циклы еще раз, получаем следующий результат.

avgSetProperty     0.10900000214576722
avgSetAttribute    0.10399999618530273

Картина изменилась. Средняя скорость обоих вариантов приблизительно сравнялась. "setAttribute" оказался даже немного быстрее, но эту разницу можно списать на погрешность. И причина тому вовсе даже не валидация, здесь она пока еще не значительна. В данном случае в игру вступает еще один процесс - мутация объекта CSSStyleDeclaration. Этот интерфейс описывает структуру набор стилей, такого как например, тело тэга <style>. Такой же объект хранит и стиль отдельно взятого элемента. Я уже приводил листинг метода установки значения свойства в CSSStyleDeclaration. Давайте взглянем на него еще раз.

/third_party/blink/renderer/core/css/abstract_property_set_css_style_declaration.cc#236

void AbstractPropertySetCSSStyleDeclaration::SetPropertyInternal(
    CSSPropertyID unresolved_property,
    const String& custom_property_name,
    StringView value,
    bool important,
    SecureContextMode secure_context_mode,
    ExceptionState&) {
  StyleAttributeMutationScope mutation_scope(this);
  WillMutate();

  MutableCSSPropertyValueSet::SetResult result;
  if (unresolved_property == CSSPropertyID::kVariable) {
    AtomicString atomic_name(custom_property_name);

    bool is_animation_tainted = IsKeyframeStyle();
    result = PropertySet().ParseAndSetCustomProperty(
        atomic_name, value, important, secure_context_mode, ContextStyleSheet(),
        is_animation_tainted);
  } else {
    result = PropertySet().ParseAndSetProperty(unresolved_property, value,
                                               important, secure_context_mode,
                                               ContextStyleSheet());
  }

  if (result == MutableCSSPropertyValueSet::kParseError ||
      result == MutableCSSPropertyValueSet::kUnchanged) {
    DidMutate(kNoChanges);
    return;
  }

  CSSPropertyID property_id = ResolveCSSPropertyID(unresolved_property);

  if (result == MutableCSSPropertyValueSet::kModifiedExisting &&
      CSSProperty::Get(property_id).SupportsIncrementalStyle()) {
    DidMutate(kIndependentPropertyChanged);
  } else {
    DidMutate(kPropertyChanged);
  }

  mutation_scope.EnqueueMutationRecord();
}

Первым делом объект блокируется. Далее парсится и сохраняется значение свойства. После чего блокировка снимается.

А вот так выглядит установка стиля целиком, через текстовую строку.

/third_party/blink/renderer/core/css/abstract_property_set_css_style_declaration.cc#54

void AbstractPropertySetCSSStyleDeclaration::setCSSText(
    const ExecutionContext* execution_context,
    const String& text,
    ExceptionState&) {
  StyleAttributeMutationScope mutation_scope(this);
  WillMutate();

  const SecureContextMode mode = execution_context
                                     ? execution_context->GetSecureContextMode()
                                     : SecureContextMode::kInsecureContext;
  PropertySet().ParseDeclarationList(text, mode, ContextStyleSheet());

  DidMutate(kPropertyChanged);

  mutation_scope.EnqueueMutationRecord();
}

Тот же самый объект так же блокируется. Дальше текстовая строка парсится целиком и разбирается на свойства. Значения сохраняются и объект разблокируется.

Таким образом, вызывая style.setProperty два раза, мы инициируем процесс блокировки-парсинга-разблокировки дважды. В отличие от setAttribute, который способен распарсить весь стиль за один раз.

Не могу не отметить один момент, касающийся оптимизации парсинга стилей.

/third_party/blink/renderer/core/css/parser/css_parser_impl.cc#255

 static ImmutableCSSPropertyValueSet* CreateCSSPropertyValueSet(
    HeapVector<CSSPropertyValue, 64>& parsed_properties,
    CSSParserMode mode,
    const Document* document) {
  if (mode != kHTMLQuirksMode &&
      (parsed_properties.size() < 2 ||
       (parsed_properties.size() == 2 &&
        parsed_properties[0].Id() != parsed_properties[1].Id()))) {
    // Fast path for the situations where we can trivially detect that there can
    // be no collision between properties, and don't need to reorder, make
    // bitsets, or similar.
    ImmutableCSSPropertyValueSet* result =
        ImmutableCSSPropertyValueSet::Create(parsed_properties, mode);
    parsed_properties.clear();
    return result;
  }
  
  ...
}

Парсер, разобрав строку, получает некий массив свойств. Однако, этот массив может содержать дублирующиеся свойства. Для того, чтобы создать набор уникальных свойств, потребуется занова пройти по массиву и собрать сет. Однако, если в исходном массиве всего два свойства, проверить их на уникальность можно простым if-ом сравнив их по id. Мелочь, а приятно.

Испытание 3. Множество свойств

Проведем еще одно испытание. На этот раз возьмем свойств побольше. Скажем, семь. Почему именно семь? Это число выбрано неспроста. Но об этом чуть ниже.

async function handleSetProperty() {
  const durations = [];

  for await (const i of new Array(N).fill(true).map((_, index) => index)) {
    const el = createElement();

    await sleep(300);

    const startTime = performance.now();
    el.style.setProperty("background-color", "red");
    el.style.setProperty("border", "1px solid blue");
    el.style.setProperty("position", "relative");
    el.style.setProperty("display", "flex");
    el.style.setProperty("align-items", "center");
    el.style.setProperty("text-align", "center");
    el.style.setProperty("text-transform", "uppercase");
    const duration = performance.now() - startTime;

    durations.push(duration);

    await sleep(300);

    console.log(i);
  }

  console.log(durations);
}

async function handleSetAttribute() {
  const durations = [];

  for await (const i of new Array(N).fill(true).map((_, index) => index)) {
    const el = createElement();

    await sleep(300);

    const startTime = performance.now();
    el.setAttribute(
      "style",
      "background-color: red; border: 1px solid blue; position: relative; display: flex; align-items: center; text-align: center; text-transform: uppercase;",
    );
    const duration = performance.now() - startTime;

    durations.push(duration);

    await sleep(300);

    console.log(i);
  }

  console.log(durations);
}

Результаты этого испытания вполне логичны.

avgSetProperty     0.17899999499320984
avgSetAttribute    0.12500000596046448

На этот раз setAttribute одержал безоговорочную победу в скорости по выше упомянутым причинам.

Испытание 4. Множество числовых значений

Вы наверняка заметили, что в предыдущем испытании все свойства имели строковые значения. Дело в том, что числовые значения, пришедшие из JavaScript не требуют их дополнительного парсинга из строки. Что позволяет сделать еще одну оптимизацию и немного сэкономить на этом.

К сожалению, таких свойств не много. Большинство привычных нам свойств, которые могут принимать числа, умеют работать, например, с разными единицами измерения, делать разные математические операции и т.д. Что заставляет в любом случае конвертировать их числовое значение во что-то иное. Поэтому разработчики ограничили набор возможных свойств с числовыми значениями. На данный момент таких свойств всего семь: opacity, fill-opacity, flood-opacity, stop-opacity, stroke-opacity, shape-image-threshold и -webkit-box-flex.

Повторим наш предыдущий эксперимент, но теперь только с числовыми свойствами. Собственно, именно по этому я и взял в прошлый раз только семь штук, дабы была возможность сравнить результаты.

async function handleSetProperty() {
  const durations = [];

  for await (const i of new Array(N).fill(true).map((_, index) => index)) {
    const el = createElement();

    await sleep(300);

    const startTime = performance.now();
    el.style.setProperty("opacity", 0.5);
    el.style.setProperty("fill-opacity", 0.5);
    el.style.setProperty("flood-opacity", 0.5);
    el.style.setProperty("stop-opacity", 0.5);
    el.style.setProperty("stroke-opacity", 0.5);
    el.style.setProperty("shape-image-threshold", 0.5);
    el.style.setProperty("-webkit-box-flex", 1);

    const duration = performance.now() - startTime;

    durations.push(duration);

    await sleep(300);

    console.log(i);
  }

  console.log(durations);
}

async function handleSetAttribute() {
  const durations = [];

  for await (const i of new Array(N).fill(true).map((_, index) => index)) {
    const el = createElement();

    await sleep(300);

    const startTime = performance.now();
    el.setAttribute(
      "style",
      "opacity: 0.5; fill-opacity: 0.5; flood-opacity: 0.5; stop-opacity: 0.5; stroke-opacity: 0.5; shape-image-threshold: 0.5; -webkit-box-flex: 1;",
    );
    const duration = performance.now() - startTime;

    durations.push(duration);

    await sleep(300);

    console.log(i);
  }

  console.log(durations);
}

И теперь результат.

avgSetProperty     0.17099999666213989
avgSetAttribute    0.09600000023841858

setAttribute все так же быстрее. Всё таки, расходы на конвертацию строки в число по производительности не идут в сравнение с процессом блокировки-разблокировки и записи значения. Но тем не менее, в обоих случаях результат оказался немного лучше, чем в испытании 3.

Вывод

Подытожим всё выше сказанное.

1. style.setProperty показывает себя быстрее, в случае установки одного единственного свойства. Если устанавливается одновременно 2 и более свойств, быстрее будет setAttribute.
2. setAttribute не валидирует значения. Это может быть как плюсом, так и минусом. Если нам важно, чтобы выставлялись только корректные значения, можно воспользоваться сеттером element.style = "<стиль>". Однако, если нам требуется установить на элементе произвольный атрибут или заведомо не корректное значение, без setAttribute не обойтись.
3. Существует семь свойств, которым разрешено принимать числовые значения из JS-скрипта. Установка значений этих свойств будет немного быстрее за счет исключения операции конвертации строки в число.

Мои телеграмм-каналы:

English version: https://blog.frontend-almanac.com/style-setproperty-vs-setattribute

Для того чтобы лучше понять, что происходит под капотом V8, для начала стоит вспомнить немного теории.

Спецификация ECMA-262 гласит:

The String type is the set of all ordered sequences of zero or more 16-bit unsigned integer values (“elements”) up to a maximum length of 2**53 - 1 elements.

Тип String — это набор всех упорядоченных последовательностей из нуля или более 16-разрядных целых беззнаковых чисел (“элементов”) максимальной длиной 2**53 - 1 элементов.

На практике в машинной памяти вместе со строками необходимо хранить дополнительную информацию, чтобы иметь возможность определить конец строки в общей куче. Для этой цели существует два подхода. Первый — массив символов: структура, представляющая собой последовательность элементов и отдельное поле — длину этой последовательности. Второй — метод завершающего байта, то есть в конце последовательности элементов должен стоять некий служебный символ, обозначающий конец строки. В качестве завершающего символа, в зависимости от системы, может выступать байт 0xFF или, например, ASCII-код символа. Но наибольшее распространение получил байт 0x00. А строки с таким завершающим элементом получили название нуль-терминированные. Оба метода имеют свои плюсы и минусы, поэтому в современном мире часто оба метода объединяют, и строки в памяти могут одновременно быть нуль-терминированными и хранить значение длины. Например, в языке C++ начиная с версии 11.

Кроме общего определения строки, спецификация ECMA-262 имеет ряд других требований наряду с остальными типами данных языка JavaScript. Подробно о типах и их представлении внутри движка V8 я писал в статье "Глубокий JS. В память о типах и данных". В этой статье мы узнали, что все типы имеют свой скрытый класс, который хранит всю необходимую атрибутику, служебную информацию, а также инкапсулирует логику работы с этим типом. Очевидно, что для работы со строками стандартной библиотеки C++ std::string — недостаточно, и они преобразуются во внутренний класс v8::String.

Какие бывают строки

Дабы обеспечить все требования спецификации и в силу различных оптимизаций, строки внутри V8 делятся на разные типы.

Однобайтные / Двубайтные

Несмотря на то что спецификация прямо определяет все строки как последовательность 16-разрядных элементов, с точки зрения оптимизации это довольно расточительно. Ведь далеко не всем символам требуется 2 байта для представления. Стандартная таблица ASCII содержит 128 элементов, среди которых арабские цифры, буквы латинского алфавита в верхнем и нижнем регистрах без диакритических знаков, основные знаки препинания, математические знаки и управляющие символы. Вся эта таблица предполагает кодирование всего 8 битами, при этом сам набор символов является широко распространенным и встречается на практике наиболее часто. В связи с этим разработчиками V8 было принято решение кодировать те строки, которые содержат только 8-разрядные символы, отдельно от стандартных 16-разрядных. Это позволяет существенно экономить память.

Интернализированные / Экстернализированные строки

Помимо разрядности, строки различаются местом хранения. После преобразования во внутреннюю структуру строка попадает в так называемую таблицу строк (StringTable), о которой мы поговорим чуть ниже. Пока обозначу, что таких таблиц три. Собственно, сама StringTable хранит строки внутри одного Isolate (грубо говоря, внутри одного таба браузера). Кроме того, движок позволяет хранить строки за пределами кучи, и даже за пределами самого движка во внешнем хранилище. Указатели на такие строки помещаются в отдельную таблицу ExternalStringTable. Дополнительно есть еще одна таблица — StringForwardingTable для нужд сборщика мусора. Да, строки, как и объекты, участвуют в процессе сборки мусора, и так как хранятся они в отдельных таблицах, им для этого нужны специфические механизмы. Об этом тоже чуть ниже.

Строки по назначение

Язык JavaScript является довольно гибким. Во время исполнения кода строки могут многократно трансформироваться и участвовать в смежных процессах. Для большей производительности им выделено несколько функциональных типов. К ним относятся: SeqString, ConsString, ThinString, SlicedString и ExternalString. О каждом типе мы поговорим подробно далее. А пока давайте соберём всё вышесказанное вместе.

Так выглядит общая классификация типов строк в V8. Помимо основных, есть ещё несколько производных типов. Например, SeqString и ExternalString могут быть размещены в общей Shared-куче, тогда их типы могут быть SharedSeq<one|two>ByteString и SharedExternal<one|two>ByteString соответственно. Кроме того, ExternalString может быть некэшируемым и иметь дополнительные типы UncachableExternal<one|two>ByteString и даже SharedUncachableExternal<one|two>ByteString.

AST

Прежде чем строка приобретёт свой окончательный вид в недрах V8, движок должен её сначала прочитать и интерпретировать. Делается это тем же механизмом, что и интерпретация всех остальных синтаксических единиц языка. А именно, посредством составления абстрактного синтаксического дерева (AST), про которое я говорил в статье Глубокий JS. Области тьмы или где живут переменные.

Получив на вход строковую ноду через строковый литерал или каким-то другим образом, V8 создаёт экземпляр класса AstRawString. Если строка является конкатенацией двух или более других строк, то AstConsString. Эти классы предназначены для хранения строк вне кучи V8, в так называемой AstValueFactory. Позже этим строкам будет определён тип, и они будут интернализированы, т.е. перемещены в кучу V8.

Длина строки

Размер каждой строки в памяти зависит от её длины. Чем длиннее строка, тем больше памяти она занимает. Но существуют ли какие-то ограничения на максимальный размер строки со стороны движка? Спецификация прямо указывает на то, что строка не может быть больше 2**53 - 1 элементов. Однако на практике это число может быть другим. Ведь тогда максимальная однобайтная строка весила бы 8 192 ТБ (8 ПБ), а двубайтная, соответственно, 4 096 ТБ (4 ПБ). Очевидно, что ни один персональный компьютер не имеет такого количества оперативной памяти, поэтому JS-движки имеют свои собственные лимиты, которые значительно строже требований спецификации. Конкретно в V8 (версия V8 на момент написания статьи 12.8.325) максимальная длина строки зависит от архитектуры системы.

/include/v8-primitive.h#126

static constexpr int kMaxLength =
    internal::kApiSystemPointerSize == 4 ? (1 << 28) - 16 : (1 << 29) - 24;

Для 32-разрядных систем это число 2**28 - 16, а в 64-разрядных — чуть больше: 2**29 - 24. Такие ограничения не позволят в 32-разрядных системах одной однобайтной строке занять более 256 МБ, а двубайтной — более 512 МБ. В 64-разрядных системах максимальные значения составляют соответственно не более 512 МБ и не более 1024 МБ. В случае если строка превысит лимит длины, движок вернёт ошибку Invalid string length.

const length = (1 << 29) - 24;
const longString = '"' + new Array(length - 2).join('x');

String.prototype.link(longString); // RangeError: Invalid string length

Объективности ради стоит отметить, что косвенную роль играет и максимальный размер самой кучи, так как он не является константой и может регулироваться системой или конфигурацией движка.

// d8 --max-heap-size=128

const length = (1 << 27) + 24; // 129 MB
const longString = '"' + new Array(length - 2).join('x');

String.prototype.link(longString);

// Fatal JavaScript out of memory: Reached heap limit

StringTable

В ходе выполнения JS-программа может оперировать большим количеством как самих строк, так и переменных, которые на них ссылаются. Как мы увидели, каждая строка может потреблять значительный объём памяти. При этом сами строки в ходе выполнения JS-программы могут многократно клонироваться, изменяться, склеиваться и вообще трансформироваться самыми разными способами. В результате этого в памяти могут оказаться дубликаты строковых значений. Хранить множество копий одной и той же последовательности символов было бы крайне расточительно, поэтому в мире системного программирования уже давно активно применяется практика хранения строковых значений в некой отдельной структуре, которая заботится о том, чтобы в ней не было дублирования значений, а все строковые переменные ссылались на эту структуру. В Java и .NET, например, такая структура называется "StringPool", а в JavaScript - StringTable.

Суть в том, что после того, как строка попала в AST-дерево, для неё на основании типа и значения генерируется хэш-ключ. Сгенерированный ключ сохраняется в объекте строки, и далее по нему запускается проверка наличия строки в специальной таблице строк, размещённой в куче. Если такой ключ есть в таблице, соответствующая JS-переменная получит ссылку на существующий объект строки. В противном случае будет создан новый объект строки, а ключ будет помещён в таблицу. Этот процесс называется интернмазацией.

InternalizedString

Чуть выше я говорил, что во внутреннем представлении V8 существует множество типов строк. Интернализированные строки в своём самом базовом варианте получают тип InternalizedString, который указывает на то, что строка находится в StringTable.

Как обычно, давайте посмотрим на структуру строки внутри движка, скомпилировав V8 в режиме debug и запустив её с флагом --allow-natives-syntax.

d8> %DebugPrint("FrontendAlmanac")

DebugPrint: 0x28db000d9b99: [String] in OldSpace: #FrontendAlmanac
0x28db000003d5: [Map] in ReadOnlySpace
 - map: 0x28db000004c5 <MetaMap (0x28db0000007d <null>)>
 - type: INTERNALIZED_ONE_BYTE_STRING_TYPE
 - instance size: variable
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - non-extensible
 - back pointer: 0x28db00000061 <undefined>
 - prototype_validity cell: 0
 - instance descriptors (own) #0: 0x28db00000701 <DescriptorArray[0]>
 - prototype: 0x28db0000007d <null>
 - constructor: 0x28db0000007d <null>
 - dependent code: 0x28db000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

Первое, что мы здесь видим, это тип INTERNALIZED_ONE_BYTE_STRING_TYPE, что означает, что строка является однобайтной и помещена в StringTable. Давайте попробуем создать ещё один строковый литерал с тем же значением.

d8> const string2 = "FrontendAlmanac";
d8> %DebugPrint(string2);

DebugPrint: 0x28db000d9b99: [String] in OldSpace: #FrontendAlmanac
0x28db000003d5: [Map] in ReadOnlySpace
 - map: 0x28db000004c5 <MetaMap (0x28db0000007d <null>)>
 - type: INTERNALIZED_ONE_BYTE_STRING_TYPE
 - instance size: variable
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - non-extensible
 - back pointer: 0x28db00000061 <undefined>
 - prototype_validity cell: 0
 - instance descriptors (own) #0: 0x28db00000701 <DescriptorArray[0]>
 - prototype: 0x28db0000007d <null>
 - constructor: 0x28db0000007d <null>
 - dependent code: 0x28db000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

Обратите внимание, что константа string2 ссылается ровно на тот же экземпляр строки по адресу 0x28db000d9b99.

Аналогичную картину мы можем увидеть и в браузере Chrome.

// Замкнем значения в функции
function V8Snapshot() {
  this.string1 = "FrontendAlmanac";
  this.string2 = "FrontendAlmanac";
}

const v8Snapshot = new V8Snapshot();

Оба свойства V8Snapshot ссылаются на один и тот же адрес @61559. Содержимое всей StringTable можно увидеть тут же, в слепке в объекте (string).

Здесь мы можем найти нашу строку и посмотреть, какие переменные на неё ссылаются.

Вы наверняка заметили, что в таблице помимо нашей строки есть ещё более 4к других значений. Дело в том, что V8 хранит здесь, в том числе, свои служебные строки, такие как ключевые слова, различные названия системных методов и функций, и даже тексты JS-скриптов.

SeqString

Понятие InternalizedString появилось сравнительно недавно, в 2018 году, в рамках оптимизирующего компилятора TurboFan. До этого простые строки имели тип SeqString. Технически, InternalizedString отличается от SeqString своей внутренней структурой. Если точнее, в классах SeqOneByteString и SeqTwoByteString имеется указатель на массив символов chars и ряд методов, которые умеют взаимодействовать с ним. Имплементация класса SeqString выглядит буквально следующим образом:

/src/objects/string.h#733

// The SeqString abstract class captures sequential string values.
class SeqString : public String {
 public:
  // Truncate the string in-place if possible and return the result.
  // In case of new_length == 0, the empty string is returned without
  // truncating the original string.
  V8_WARN_UNUSED_RESULT static Handle<String> Truncate(Isolate* isolate,
                                                       Handle<SeqString> string,
                                                       int new_length);
                                                       
  struct DataAndPaddingSizes {
    const int data_size;
    const int padding_size;
    bool operator==(const DataAndPaddingSizes& other) const {
      return data_size == other.data_size && padding_size == other.padding_size;
    }
  };
  DataAndPaddingSizes GetDataAndPaddingSizes() const;
  
  // Zero out only the padding bytes of this string.
  void ClearPadding();
  
  EXPORT_DECL_VERIFIER(SeqString)
};

А один из его наследников, SeqOneByteString, так:

/src/objects/string.h#763

// The OneByteString class captures sequential one-byte string objects.
// Each character in the OneByteString is an one-byte character.
V8_OBJECT class SeqOneByteString : public SeqString {
 public:
  static const bool kHasOneByteEncoding = true;
  using Char = uint8_t;
  
  V8_INLINE static constexpr int32_t DataSizeFor(int32_t length);
  V8_INLINE static constexpr int32_t SizeFor(int32_t length);
  
  // Dispatched behavior. The non SharedStringAccessGuardIfNeeded method is also
  // defined for convenience and it will check that the access guard is not
  // needed.
  inline uint8_t Get(int index) const;
  inline uint8_t Get(int index,
                     const SharedStringAccessGuardIfNeeded& access_guard) const;
  inline void SeqOneByteStringSet(int index, uint16_t value);
  inline void SeqOneByteStringSetChars(int index, const uint8_t* string,
                                       int length);
                                       
  // Get the address of the characters in this string.
  inline Address GetCharsAddress() const;
  
  // Get a pointer to the characters of the string. May only be called when a
  // SharedStringAccessGuard is not needed (i.e. on the main thread or on
  // read-only strings).
  inline uint8_t* GetChars(const DisallowGarbageCollection& no_gc);
  
  // Get a pointer to the characters of the string.
  inline uint8_t* GetChars(const DisallowGarbageCollection& no_gc,
                           const SharedStringAccessGuardIfNeeded& access_guard);
                           
  DataAndPaddingSizes GetDataAndPaddingSizes() const;
  
  // Initializes padding bytes. Potentially zeros tail of the payload too!
  inline void clear_padding_destructively(int length);
  
  // Maximal memory usage for a single sequential one-byte string.
  static const int kMaxCharsSize = kMaxLength;
  
  inline int AllocatedSize() const;
  
  // A SeqOneByteString have different maps depending on whether it is shared.
  static inline bool IsCompatibleMap(Tagged<Map> map, ReadOnlyRoots roots);
  
  class BodyDescriptor;
  
 private:
  friend struct OffsetsForDebug;
  friend class CodeStubAssembler;
  friend class ToDirectStringAssembler;
  friend class IntlBuiltinsAssembler;
  friend class StringBuiltinsAssembler;
  friend class StringFromCharCodeAssembler;
  friend class maglev::MaglevAssembler;
  friend class compiler::AccessBuilder;
  friend class TorqueGeneratedSeqOneByteStringAsserts;
  
  FLEXIBLE_ARRAY_MEMBER(Char, chars);
} V8_OBJECT_END;

Для сравнения, класс InternalizedString выглядит следующим образом:

/src/objects/string.h#758

V8_OBJECT class InternalizedString : public String{

  // TODO(neis): Possibly move some stuff from String here.
} V8_OBJECT_END;

Как видите, здесь вообще нет никакой реализации, так как само понятие InternalizedString было введено лишь для удобства терминологии. Фактически, вся логика по выделению памяти, кодированию и декодированию, сравнению и модификации строк лежит в базовом классе String. Символы хранятся не в виде массива, а непосредственно в виде 32-разрядной или 64-разрядной последовательности кодов символов в памяти. Сам класс имеет только системный указатель на начало соответствующей области. Такая структура называется "FlatContent", а такие строки соответственно — плоскими.

V8_OBJECT class String : public Name {
  ...
 private:
  union {
    const uint8_t* onebyte_start;
    const base::uc16* twobyte_start;
  };
  ...
}

Так что же такое SeqString на практике?

d8> const seqString = [
  "F", "r", "o", "n", "t", "e", "n", "d",
  "A", "l", "m", "a", "n", "a", "c"
].join("");
d8> 
d8> %DebugPrint(seqString);

DebugPrint: 0x2353001c94e1: [String]: "FrontendAlmanac"
0x235300000105: [Map] in ReadOnlySpace
 - map: 0x2353000004c5 <MetaMap (0x23530000007d <null>)>
 - type: SEQ_ONE_BYTE_STRING_TYPE
 - instance size: variable
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - non-extensible
 - back pointer: 0x235300000061 <undefined>
 - prototype_validity cell: 0
 - instance descriptors (own) #0: 0x235300000701 <DescriptorArray[0]>
 - prototype: 0x23530000007d <null>
 - constructor: 0x23530000007d <null>
 - dependent code: 0x2353000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

В примере выше строка создана посредством объединения элементов массива. Так как во время этой операции массив в любом случае должен был создаться, а итоговую строку нельзя проверить в StringTable, пока она не будет объединена, переменная получает тип SeqString.

Давайте немного изменим предыдущий пример.

function V8Snapshot() {
  this.string1 = "FrontendAlmanac";
  this.string2 = [
    "F", "r", "o", "n", "t", "e", "n", "d",
    "A", "l", "m", "a", "n", "a", "c"
  ].join("");
}

const v8Snapshot = new V8Snapshot();

Как будет выглядеть таблица строк в этом случае?

Так как string1 и string2 — два разных объекта с разными типами строк, каждая из них имеет свой собственный адрес. Более того, у каждой из них будет свой уникальный хэш-ключ. Поэтому в таблице мы можем видеть два одинаковых значения с разными ключами. Другими словами, имеются дубликаты строк. Вообще, все подобные дубликаты можно увидеть, применив фильтр Duplicated strings в слепке.

Более того, если мы попытаемся создать несколько SeqString с одинаковым значением, их дубликаты также не будут в таблице.

function V8Snapshot() {
  this.string1 = "FrontendAlmanac";
  this.string2 = [
    "F", "r", "o", "n", "t", "e", "n", "d",
    "A", "l", "m", "a", "n", "a", "c"
  ].join("");
  this.string3 = [
    "F", "r", "o", "n", "t", "e", "n", "d",
    "A", "l", "m", "a", "n", "a", "c"
  ].join("");
}

const v8Snapshot = new V8Snapshot();

ConsString

Рассмотрим еще один пример

d8> const consString = "Frontend" + "Almanac";
d8> %DebugPrint(consString);

DebugPrint: 0xf0001c952d: [String]: c"FrontendAlmanac"
0xf000000155: [Map] in ReadOnlySpace
 - map: 0x00f0000004c5 <MetaMap (0x00f00000007d <null>)>
 - type: CONS_ONE_BYTE_STRING_TYPE
 - instance size: 20
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - non-extensible
 - back pointer: 0x00f000000061 <undefined>
 - prototype_validity cell: 0
 - instance descriptors (own) #0: 0x00f000000701 <DescriptorArray[0]>
 - prototype: 0x00f00000007d <null>
 - constructor: 0x00f00000007d <null>
 - dependent code: 0x00f0000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

Переменная consString образована конкатенацией двух строковых литералов. Такие строки получают тип ConsString.

/src/objects/string.h#916

V8_OBJECT class ConsString : public String {
 public:
  inline Tagged<String> first() const;
  inline void set_first(Tagged<String> value,
                        WriteBarrierMode mode = UPDATE_WRITE_BARRIER);
  
  inline Tagged<String> second() const;
  inline void set_second(Tagged<String> value,
                         WriteBarrierMode mode = UPDATE_WRITE_BARRIER);
  
  // Doesn't check that the result is a string, even in debug mode.  This is
  // useful during GC where the mark bits confuse the checks.
  inline Tagged<Object> unchecked_first() const;
  
  // Doesn't check that the result is a string, even in debug mode.  This is
  // useful during GC where the mark bits confuse the checks.
  inline Tagged<Object> unchecked_second() const;
  
  V8_INLINE bool IsFlat() const;
  
  // Dispatched behavior.
  V8_EXPORT_PRIVATE uint16_t
  Get(int index, const SharedStringAccessGuardIfNeeded& access_guard) const;
  
  // Minimum length for a cons string.
  static const int kMinLength = 13;
  
  DECL_VERIFIER(ConsString)
  
 private:
  friend struct ObjectTraits<ConsString>;
  friend struct OffsetsForDebug;
  friend class V8HeapExplorer;
  friend class CodeStubAssembler;
  friend class ToDirectStringAssembler;
  friend class StringBuiltinsAssembler;
  friend class maglev::MaglevAssembler;
  friend class compiler::AccessBuilder;
  friend class TorqueGeneratedConsStringAsserts;
  
  friend Tagged<String> String::GetUnderlying() const;
  
  TaggedMember<String> first_;
  TaggedMember<String> second_;
} V8_OBJECT_END;

Класс ConsString имеет два указателя на другие строки, которые, в свою очередь, могут быть любого типа, в том числе и ConsString. В результате этого данный тип может образовывать бинарное дерево из ConsString, листья которого не ConsString. Итоговое значение такой строки получается конкатенацией листьев дерева слева направо, от самого глубокого узла к первому.

function V8Snapshot() {
  this.string1 = "FrontendAlmanac";
  this.string2 = "Frontend" + "Almanac";
  this.string3 = "Frontend" + "Almanac";
}

const v8Snapshot = new V8Snapshot();

Как и в случае с SeqString, каждая конкатенированная строка имеет свой собственный экземпляр класса и, соответственно, хэш-ключ. Такие строки также могут дублироваться в таблице строк. Однако, в таблице мы также сможем найти интернализированные листья этой конкатенации.

Важно сделать оговорку. Не любая операция конкатенации приводит к созданию ConsString.

d8> const string = "a" + "b";
d8> %DebugPrint(string);

DebugPrint: 0x1d48001c9ec5: [String]: "ab"
0x1d4800000105: [Map] in ReadOnlySpace
 - map: 0x1d48000004c5 <MetaMap (0x1d480000007d <null>)>
 - type: SEQ_ONE_BYTE_STRING_TYPE
 - instance size: variable
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - non-extensible
 - back pointer: 0x1d4800000061 <undefined>
 - prototype_validity cell: 0
 - instance descriptors (own) #0: 0x1d4800000701 <DescriptorArray[0]>
 - prototype: 0x1d480000007d <null>
 - constructor: 0x1d480000007d <null>
 - dependent code: 0x1d48000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

В примере выше строка представлена типом SeqString. Дело в том, что процедуры чтения и записи в структуру ConsString не бесплатны. Хотя сама структура считается эффективной с точки зрения оптимизации памяти, все преимущества проявляются только на относительно длинных строках. В случае же коротких строк накладные расходы по содержанию бинарного дерева сводят на нет все эти преимущества. Поэтому разработчики V8 эмпирическим путем определили критическую длину строки, короче которой структура ConsString неэффективна. Это число — 13.

/src/objects/string.h#940

// Minimum length for a cons string.
static const int kMinLength = 13;

SlicedString

d8> const parentString = " FrontendAlmanac FrontendAlmanac ";
d8> const slicedString1 = parentString.substring(1, 16);
d8> const slicedString2 = parentString.slice(1, 16);
d8> const slicedString3 = parentString.trim();
d8> 
d8> %DebugPrint(slicedString1);

DebugPrint: 0x312b001c9509: [String]: "FrontendAlmanac"
0x312b000001a5: [Map] in ReadOnlySpace
 - map: 0x312b000004c5 <MetaMap (0x312b0000007d <null>)>
 - type: SLICED_ONE_BYTE_STRING_TYPE
 - instance size: 20
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - non-extensible
 - back pointer: 0x312b00000061 <undefined>
 - prototype_validity cell: 0
 - instance descriptors (own) #0: 0x312b00000701 <DescriptorArray[0]>
 - prototype: 0x312b0000007d <null>
 - constructor: 0x312b0000007d <null>
 - dependent code: 0x312b000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

Этот тип присваивается строкам, образованным как результат подстроки другой строки. К таким операциям относятся substring(), slice() и методы тримминга trim(), trimStart(), trimEnd().

Класс SlicedString хранит только указатель на родительскую строку, а также смещение и длину последовательности в родительской строке. Это позволяет значительно сократить расход памяти и время при работе с такими строками. Однако здесь действует то же правило, что и в ConsString: длина подстроки не должна быть меньше 13 символов. В противном случае эта оптимизация не имеет смысла, так как, помимо памяти, SlicedString требует распаковки родительской строки и последующего добавления смещения к стартовому адресу последовательности.

Еще одной важной особенностью является то, что SlicedString не может быть вложенной.

function V8Snapshot() {
  this.parentString = " FrontendAlmanac FrontendAlmanac ";
  this.slicedString1 = this.parentString.trim();
  this.slicedString2 = this.slicedString1.substring(0, 15);
}

const v8Snapshot = new V8Snapshot();

В примере выше мы пытаемся создать SlicedString от другой SlicedString. Однако slicedString1 не может выступать в роли родительской строки, так как сама является SlicedString.

Поэтому родительской строкой для обоих свойств будет parentString.

ThinString

Бывает так, что нужно провести интернализацию строки, но по какой-то причине сделать это прямо сейчас нельзя. В таком случае создаётся новый объект строки, интернализируется, а оригинальная строка конвертируется в тип ThinString, который, по сути, является ссылкой на свою интернализированную версию. ThinString очень похож на ConsString, только с одной ссылкой.

d8> const string = "Frontend" + "Almanac"; // создаем ConsString
d8> const obj = {};
d8> 
d8> obj[string]; // конвертируем в ThinString
d8> 
d8> %DebugPrint(string);

DebugPrint: 0x335f001c947d: [String]: >"FrontendAlmanac"
0x335f00000425: [Map] in ReadOnlySpace
 - map: 0x335f000004c5 <MetaMap (0x335f0000007d <null>)>
 - type: THIN_ONE_BYTE_STRING_TYPE
 - instance size: 16
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - non-extensible
 - back pointer: 0x335f00000061 <undefined>
 - prototype_validity cell: 0
 - instance descriptors (own) #0: 0x335f00000701 <DescriptorArray[0]>
 - prototype: 0x335f0000007d <null>
 - constructor: 0x335f0000007d <null>
 - dependent code: 0x335f000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

В примере выше мы первым делом создаём ConsString. Далее мы используем эту строку в качестве ключа объекта. Чтобы найти ключ в массиве свойств объекта, строка должна быть плоской, однако сейчас она представляет собой бинарное дерево с двумя узлами. В этом случае движок вынужден вычислить плоское значение из ConsString, создать новый объект строки и интернализировать его, а оригинальную строку сконвертировать в ThinString. Подобный кейс, кстати, упоминался в статье про очистку строк на Хабре, правда, не было объяснено, почему так происходит.

Давайте посмотрим в DevTools. ThinString тут мы не увидим. Но можно заметить, что свойство string представлено как InternalizedString, так как ThinString — это, повторюсь, лишь ссылка на интернализированную версию строки.

ExternalString

Еще одним типом строк является ExternalString. Движок V8 предусматривает возможность создания и хранения строк за пределами самого движка. Специально для этого был введён тип ExternalString и соответствующее API. Ссылки на эти строки хранятся в отдельной таблице ExternalStringTable в куче. Как правило, такие строки создаются потребителем движка для каких-либо собственных нужд. Например, браузеры могут таким образом хранить какие-то внешние ресурсы. Также потребитель может полностью контролировать жизненный цикл этих ресурсов, но с одной оговоркой: потребитель должен гарантировать, что такая строка не будет деаллоцирована, пока объект ExternalString жив в куче V8.

На скриншоте выше как раз одна из таких строк, созданных браузером. Но мы можем создать и свою собственную. Для этого можно воспользоваться внутренним API-методом externalizeString (V8 должен быть запущен с флагом --allow-natives-syntax).

//> d8 --allow-natives-syntax --expose-externalize-string
d8> const string = "FrontendAlmanac";
d8> 
d8> externalizeString(string);
d8> 
d8> %DebugPrint(string);

DebugPrint: 0x7d6000da08d: [String] in OldSpace: #FrontendAlmanac
0x7d600000335: [Map] in ReadOnlySpace
 - map: 0x07d6000004c5 <MetaMap (0x07d60000007d <null>)>
 - type: EXTERNAL_INTERNALIZED_ONE_BYTE_STRING_TYPE
 - instance size: 20
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - non-extensible
 - back pointer: 0x07d600000061 <undefined>
 - prototype_validity cell: 0
 - instance descriptors (own) #0: 0x07d600000701 <DescriptorArray[0]>
 - prototype: 0x07d60000007d <null>
 - constructor: 0x07d60000007d <null>
 - dependent code: 0x07d6000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

Сборка мусора

Строки, как и любые другие переменные, участвуют в процессе сборки мусора. Об этом я довольно подробно писал в статье Сборка мусора в V8, поэтому останавливаться на этом не буду. Гораздо интереснее, что сама StringTable тоже участвует в процессе. Если говорить точнее, любые трансформации и удаления строк в StringTable происходят во время Full GC. Для этого используется временная таблица StringForwardingTable, в которую во время сборки мусора попадают только актуальные строки. После чего ссылка на StringTable меняется на новую таблицу.

Заключение

Итак, мы познакомились с организацией строк внутри движка V8. Узнали больше про таблицу строк и разные типы самих строк.

Немного основных моментов и выводов.

• Строки бывают однобайтные и двубайтные. Двубайтным требуется примерно в два раза больше памяти, так как каждый символ такой строки кодируется двумя байтами вне зависимости от того, является ли он символом ASCII или нет. Поэтому, если есть выбор, какую строку использовать, однобайтная в большинстве случаев будет предпочтительнее.

const myMap = {
  "Frontend Almanac": undefined, // однобайтный ключ
  "Frontend Альманах": undefined, // двубайтный ключ
}

• Несмотря на указанное в спецификации число 2**53 - 1, фактическая длина строки на реальных системах гораздо ниже. В 32-разрядных системах V8 позволяет хранить строки длиной не более 2**28 - 16 символов, а в 64-разрядных — не более 2**29 - 24.
• Seq, Cons и Sliced строки могут дублироваться в таблице строк.

const string1 = "FrontendAlmanac"; // создает интернализированную строку
const string2 = "FrontendAlmanac"; // не создает новую строку
const string3 = "Frontend" + "Almanac"; // создает дубликат строки

• SlicedString не могут быть вложенными. Они всегда ссылаются на исходную интернализированную строку. Родитель жив, пока жива хотя бы одна его дочерняя SlicedString.

let parentString = "FrontendAlmanac"; // родительская строка
let slicedString1 = parentString.slice(1); // ссылается на parentString
let slicedString2 = slicedString1.slice(1); // тоже ссылается на parentString
let slicedString3 = slicedString2.slice(1); // и эта тоже

slicedString1 = undefind;
slicedString2 = undefind;
// parentString всё еще не собрана сборщиком мусора,
// так как пока жива slicedString3

• В случае, если строка требует интернализации, но "на месте" этого сделать нельзя, например, если она Cons или Sliced, движок вычислит плоское значение, создаст новый интернализированный объект строки и сконвертирует ссылку на эту интернализированную версию.

const string = "Frontend" + "Almanac"; // ConsString

const obj = {};
obj[string]; // ThinString

// строка больше не ConsString, теперь она ThinString и ссылается на
// плоское интернализированное значение в StringTable

• Предыдущий пример можно использовать для избавления от дубликатов строк в StringTable, как, например, предложено в статье про очистку строк.

const string1 = "FrontendAlmanac";
const string2 = "Frontend" + "Almanac"; // создает дубликат
const string3 = "Frontend" + "Almanac"; // создает дубликат

const obj = {};
obj[string2]; // ThinSting
obj[string3]; // ThinString

// Теперь string2 и string3 больше не ConsString и ссылаются
// свою интернализированную версию, в данном случае на string1,
// которая уже присутствует в таблице строк.

Я описал только некоторые случаи работы со строками. Формата статьи не хватит, чтобы покрыть все возможные особенности и частные случаи. Поэтому приглашаю всех желающих описать свои случаи и задать вопросы в комментариях в моём телеграм-канале.

Мои телеграмм-каналы:

English version: https://blog.frontend-almanac.com/v8-strings

Одним из мощных инструментов, позволяющих достигнуть высокой производительности в React-приложениях, является мемоизация. Мемоизация помогает значительно сократить количество вычислений и, соответственно, обновлений интерфейса, что положительно сказывается на общей скорости и отзывчивости приложения.

В данной статье мы заглянем "под капот" движка React и увидем, как именно происходит обновление узлов. Параллельно рассмотрим и основные принципы мемоизации и её применение в различных типах компонентов.

Что такое мемоизация?

Начнем, пожалуй, с теории. Формально, мемоизацию можно определить как оптимизационную технику, применяемую для увеличения производительности программ за счёт сохранения результатов вызова функции и возвращения сохранённого результата при повторных вызовах с теми же аргументами.

В контексте React мемоизация особенно полезна для предотвращения лишних перерисовок и повышения производительности приложений. Другими словами, она помогает избегать ненужных обновлений компонентов, что делает приложение более реактивным и эффективным. Вторым не менее важным свойством мемоизации является сокращение количества дорогостоящих вычислений. Вместо того, чтобы производить их на каждом рендере компонента, можно "запомнить результат" и пересчитывать его только в случае изменения соответствующих входных параметров.

Где конкретно хранится мемоизированный результат?

Чтобы ответить на этот вопрос, нам понадобится понятие React Fiber. Подробно я описывал эту структуру в статье Детальный React. Реконсиляция, рендеры, Fiber, виртуальное дерево. Если коротко, Fiber - это некая абстрактная сущность движка React, с помощью которой описывается любой обрабатываемый узел React, будь то компонент, хук или host root. У Fiber, кроме прочего, имеются свойства pendingProps, memoizedProps и memoizedState. Именно в этих свойствах и хранится мемоизированный результат. Как именно? Посмотрим далее.

Мемоизируемые компоненты

Хоть принципы мемоизации в React одинаковы для всех сущностей, детали реализации, все таки могут отличаться, в зависимости от типа Fiber. Для понимания процесса нам потребуется пройтись по каждому типу отдельно. И начнем мы с компонентов, как самой "старой" структуры React.

Еще с первых версий React мы привыкли делить компоненты на классовые и функциональные. На самом деле, внутри движка типов компонентов куда больше. Тип компонента является типом Fiber и указывается в свойстве Fiber.tag. В выше указанной статье я приводил полный список типов для версии React 18.2, где в общей сложности насчитывалось 28 типов . В версии 18.3.1 список немного изменился, теперь их всего 26 штук.

export const FunctionComponent = 0;
export const ClassComponent = 1;
export const IndeterminateComponent = 2; // Before we know whether it is function or class
export const HostRoot = 3; // Root of a host tree. Could be nested inside another node.
export const HostPortal = 4; // A subtree. Could be an entry point to a different renderer.
export const HostComponent = 5;
export const HostText = 6;
export const Fragment = 7;
export const Mode = 8;
export const ContextConsumer = 9;
export const ContextProvider = 10;
export const ForwardRef = 11;
export const Profiler = 12;
export const SuspenseComponent = 13;
export const MemoComponent = 14;
export const SimpleMemoComponent = 15;
export const LazyComponent = 16;
export const IncompleteClassComponent = 17;
export const DehydratedFragment = 18;
export const SuspenseListComponent = 19;
export const ScopeComponent = 21;
export const OffscreenComponent = 22;
export const LegacyHiddenComponent = 23;
export const CacheComponent = 24;
export const TracingMarkerComponent = 25;

Для понимания процессов мемоизации, из этого списка нам понадобятся только три:

export const FunctionComponent = 0;
export const ClassComponent = 1;
export const MemoComponent = 14;

Когда происходит мемоизация?

Прежде чем перейти непосредственно к типам Fiber, стоит разобраться в какой конкретно момент запускается сам процесс мемоизации. В предыдущей статье я выделил четыре фазы обработки узла. Первая фаза begin определяет тип Fiber, в зависимости от которого будет запущен нужный жизненный цикл. Узлы, которые еще небыли смонтированы имеют тип IndeterminateComponent, LazyComponent или IncompleteClassComponent. Для таких Fiber будет запущен процесс монтирования. В остальных же случаях реконсиллер попытается обновить существующий узел. Если быть более конкретным, дерево решений принимается функцией beginWork реконсиллера.

/packages/react-reconciler/src/ReactFiberBeginWork.new.js#L3699

function beginWork(
  current: Fiber | null,
  workInProgress: Fiber,
  renderLanes: Lanes,
): Fiber | null {
  ...
  
  switch (workInProgress.tag) {
    case IndeterminateComponent: {
      return mountIndeterminateComponent(
        current,
        workInProgress,
        workInProgress.type,
        renderLanes,
      );
    }
    case LazyComponent: {
      const elementType = workInProgress.elementType;
      return mountLazyComponent(
        current,
        workInProgress,
        elementType,
        renderLanes,
      );
    }
    case FunctionComponent: {
      const Component = workInProgress.type;
      const unresolvedProps = workInProgress.pendingProps;
      const resolvedProps =
        workInProgress.elementType === Component
          ? unresolvedProps
          : resolveDefaultProps(Component, unresolvedProps);
      return updateFunctionComponent(
        current,
        workInProgress,
        Component,
        resolvedProps,
        renderLanes,
      );
    }
    case ClassComponent: {
      const Component = workInProgress.type;
      const unresolvedProps = workInProgress.pendingProps;
      const resolvedProps =
        workInProgress.elementType === Component
          ? unresolvedProps
          : resolveDefaultProps(Component, unresolvedProps);
      return updateClassComponent(
        current,
        workInProgress,
        Component,
        resolvedProps,
        renderLanes,
      );
    }
    case HostRoot:
      return updateHostRoot(current, workInProgress, renderLanes);
    case HostComponent:
      return updateHostComponent(current, workInProgress, renderLanes);
    case HostText:
      return updateHostText(current, workInProgress);
    case SuspenseComponent:
      return updateSuspenseComponent(current, workInProgress, renderLanes);
    case HostPortal:
      return updatePortalComponent(current, workInProgress, renderLanes);
    case ForwardRef: {
      const type = workInProgress.type;
      const unresolvedProps = workInProgress.pendingProps;
      const resolvedProps =
        workInProgress.elementType === type
          ? unresolvedProps
          : resolveDefaultProps(type, unresolvedProps);
      return updateForwardRef(
        current,
        workInProgress,
        type,
        resolvedProps,
        renderLanes,
      );
    }
    case Fragment:
      return updateFragment(current, workInProgress, renderLanes);
    case Mode:
      return updateMode(current, workInProgress, renderLanes);
    case Profiler:
      return updateProfiler(current, workInProgress, renderLanes);
    case ContextProvider:
      return updateContextProvider(current, workInProgress, renderLanes);
    case ContextConsumer:
      return updateContextConsumer(current, workInProgress, renderLanes);
    case MemoComponent: {
      const type = workInProgress.type;
      const unresolvedProps = workInProgress.pendingProps;
      // Resolve outer props first, then resolve inner props.
      let resolvedProps = resolveDefaultProps(type, unresolvedProps);
      resolvedProps = resolveDefaultProps(type.type, resolvedProps);
      return updateMemoComponent(
        current,
        workInProgress,
        type,
        resolvedProps,
        renderLanes,
      );
    }
    case SimpleMemoComponent: {
      return updateSimpleMemoComponent(
        current,
        workInProgress,
        workInProgress.type,
        workInProgress.pendingProps,
        renderLanes,
      );
    }
    case IncompleteClassComponent: {
      const Component = workInProgress.type;
      const unresolvedProps = workInProgress.pendingProps;
      const resolvedProps =
        workInProgress.elementType === Component
          ? unresolvedProps
          : resolveDefaultProps(Component, unresolvedProps);
      return mountIncompleteClassComponent(
        current,
        workInProgress,
        Component,
        resolvedProps,
        renderLanes,
      );
    }
    case SuspenseListComponent: {
      return updateSuspenseListComponent(current, workInProgress, renderLanes);
    }
    case ScopeComponent: {
      if (enableScopeAPI) {
        return updateScopeComponent(current, workInProgress, renderLanes);
      }
      break;
    }
    case OffscreenComponent: {
      return updateOffscreenComponent(current, workInProgress, renderLanes);
    }
    case LegacyHiddenComponent: {
      if (enableLegacyHidden) {
        return updateLegacyHiddenComponent(
          current,
          workInProgress,
          renderLanes,
        );
      }
      break;
    }
    case CacheComponent: {
      if (enableCache) {
        return updateCacheComponent(current, workInProgress, renderLanes);
      }
      break;
    }
    case TracingMarkerComponent: {
      if (enableTransitionTracing) {
        return updateTracingMarkerComponent(
          current,
          workInProgress,
          renderLanes,
        );
      }
      break;
    }
  }
  
  ...
}

С точки зрения мемоизации, монитруется компонент или обновляется, большой разницы нет. В конечном итоге, соответствующие методы обновления компонента будут вызваны в любом случае. Разница только в том, будут ли в эти методы переданы предыдущие значения свойств, состояния или зависимостей. Оставлю процесс трансформации монтируемыех типов в обновляемые для следующих публикаций и предлагаю перейти непосредственно к методам обновления конкретных узлов.

ClassComponent

Из наименования понятно, что данный тип присваивается классовым компонентам. На всякий случай, вспомним, как создается классовый компонент.

class MyComponent extends React.Component<{ prop1: string }> {
  render() {
    return (
      <div>
        {this.props.prop1}
      </div>
    );
  }
}

В приведенном выше beginWork обновление классовых компонентов начинается следующим образом.

const Component = workInProgress.type;
const unresolvedProps = workInProgress.pendingProps;
const resolvedProps =
  workInProgress.elementType === Component
    ? unresolvedProps
    : resolveDefaultProps(Component, unresolvedProps);
return updateClassComponent(
  current,
  workInProgress,
  Component,
  resolvedProps,
  renderLanes,
);

Первое, что тут бросается в глаза, это константа resolvedProps. Не смотря на аж 5 строк кода, эта константа всего лишь берет свойство Fiber.pendingProps, которое является ничем иным, как объектом с новыми свойствами компонента. Дабы не оставлять неясности, приведу и код функции resolveDefaultProps.

/packages/react-reconciler/src/ReactFiberLazyComponent.new.js#L12

export function resolveDefaultProps(Component: any, baseProps: Object): Object {
  if (Component && Component.defaultProps) {
    // Resolve default props. Taken from ReactElement
    const props = assign({}, baseProps);
    const defaultProps = Component.defaultProps;
    for (const propName in defaultProps) {
      if (props[propName] === undefined) {
        props[propName] = defaultProps[propName];
      }
    }
    return props;
  }
  return baseProps;
}

В переводе на человеческий язык, эта функция всего лишь присваивает дефолтные значения свойствам, если таковые были указаны при создании компонента.

class MyComponent extends React.Component<{ color?: string }> {
  static defaultProps = {
    color: 'blue',
  };

  render() {
    return (
      <div>
        {this.props.color}
      </div>
    );
  }
}

<MyComponent />              // <div>blue</div>
<MyComponent color="red" />  // <div>red</div>

Сам же механизм обновления вынесен в функцию updateClassComponent. Приведу её код в сокращенном виде, так как часть функционала в ней отвечает за обработку провайдера контекста и некоторые служебные операции для dev-mode.

/packages/react-reconciler/src/ReactFiberBeginWork.new.js#L1062

function updateClassComponent(
  current: Fiber | null,
  workInProgress: Fiber,
  Component: any,
  nextProps: any,
  renderLanes: Lanes,
) {
  ...
  const instance = workInProgress.stateNode;
  let shouldUpdate;
  if (instance === null) {
    resetSuspendedCurrentOnMountInLegacyMode(current, workInProgress);
    
    // In the initial pass we might need to construct the instance.
    constructClassInstance(workInProgress, Component, nextProps);
    mountClassInstance(workInProgress, Component, nextProps, renderLanes);
    shouldUpdate = true;
  } else if (current === null) {
    // In a resume, we'll already have an instance we can reuse.
    shouldUpdate = resumeMountClassInstance(
      workInProgress,
      Component,
      nextProps,
      renderLanes,
    );
  } else {
    shouldUpdate = updateClassInstance(
      current,
      workInProgress,
      Component,
      nextProps,
      renderLanes,
    );
  }
  const nextUnitOfWork = finishClassComponent(
    current,
    workInProgress,
    Component,
    shouldUpdate,
    hasContext,
    renderLanes,
  );
  ...
  return nextUnitOfWork;
}

Первые два if здесь отвечают за процесс монтирования нового компонента. Как я уже говорил выше, отдельно эти процессы разбирать не будем, так как в конечном итоге цикл все равно прийдет к функции обновления и вся работа с мемоизация будет происходить именно там. А именно, в функции updateClassInstance, её я приведу целиком.

/packages/react-reconciler/src/ReactFiberClassComponent.new.js#L1123

// Invokes the update life-cycles and returns false if it shouldn't rerender.
function updateClassInstance(
  current: Fiber,
  workInProgress: Fiber,
  ctor: any,
  newProps: any,
  renderLanes: Lanes,
): boolean {
  const instance = workInProgress.stateNode;
  
  cloneUpdateQueue(current, workInProgress);
  
  const unresolvedOldProps = workInProgress.memoizedProps;
  const oldProps =
    workInProgress.type === workInProgress.elementType
      ? unresolvedOldProps
      : resolveDefaultProps(workInProgress.type, unresolvedOldProps);
  instance.props = oldProps;
  const unresolvedNewProps = workInProgress.pendingProps;
  
  const oldContext = instance.context;
  const contextType = ctor.contextType;
  let nextContext = emptyContextObject;
  if (typeof contextType === 'object' && contextType !== null) {
    nextContext = readContext(contextType);
  } else if (!disableLegacyContext) {
    const nextUnmaskedContext = getUnmaskedContext(workInProgress, ctor, true);
    nextContext = getMaskedContext(workInProgress, nextUnmaskedContext);
  }
  
  const getDerivedStateFromProps = ctor.getDerivedStateFromProps;
  const hasNewLifecycles =
    typeof getDerivedStateFromProps === 'function' ||
    typeof instance.getSnapshotBeforeUpdate === 'function';
    
  // Note: During these life-cycles, instance.props/instance.state are what
  // ever the previously attempted to render - not the "current". However,
  // during componentDidUpdate we pass the "current" props.
  
  // In order to support react-lifecycles-compat polyfilled components,
  // Unsafe lifecycles should not be invoked for components using the new APIs.
  if (
    !hasNewLifecycles &&
    (typeof instance.UNSAFE_componentWillReceiveProps === 'function' ||
      typeof instance.componentWillReceiveProps === 'function')
  ) {
    if (
      unresolvedOldProps !== unresolvedNewProps ||
      oldContext !== nextContext
    ) {
      callComponentWillReceiveProps(
        workInProgress,
        instance,
        newProps,
        nextContext,
      );
    }
  }
  
  resetHasForceUpdateBeforeProcessing();
  
  const oldState = workInProgress.memoizedState;
  let newState = (instance.state = oldState);
  processUpdateQueue(workInProgress, newProps, instance, renderLanes);
  newState = workInProgress.memoizedState;
  
  if (
    unresolvedOldProps === unresolvedNewProps &&
    oldState === newState &&
    !hasContextChanged() &&
    !checkHasForceUpdateAfterProcessing() &&
    !(
      enableLazyContextPropagation &&
      current !== null &&
      current.dependencies !== null &&
      checkIfContextChanged(current.dependencies)
    )
  ) {
    // If an update was already in progress, we should schedule an Update
    // effect even though we're bailing out, so that cWU/cDU are called.
    if (typeof instance.componentDidUpdate === 'function') {
      if (
        unresolvedOldProps !== current.memoizedProps ||
        oldState !== current.memoizedState
      ) {
        workInProgress.flags |= Update;
      }
    }
    if (typeof instance.getSnapshotBeforeUpdate === 'function') {
      if (
        unresolvedOldProps !== current.memoizedProps ||
        oldState !== current.memoizedState
      ) {
        workInProgress.flags |= Snapshot;
      }
    }
    return false;
  }
  
  if (typeof getDerivedStateFromProps === 'function') {
    applyDerivedStateFromProps(
      workInProgress,
      ctor,
      getDerivedStateFromProps,
      newProps,
    );
    newState = workInProgress.memoizedState;
  }
  
  const shouldUpdate =
    checkHasForceUpdateAfterProcessing() ||
    checkShouldComponentUpdate(
      workInProgress,
      ctor,
      oldProps,
      newProps,
      oldState,
      newState,
      nextContext,
    ) ||
    // TODO: In some cases, we'll end up checking if context has changed twice,
    // both before and after `shouldComponentUpdate` has been called. Not ideal,
    // but I'm loath to refactor this function. This only happens for memoized
    // components so it's not that common.
    (enableLazyContextPropagation &&
      current !== null &&
      current.dependencies !== null &&
      checkIfContextChanged(current.dependencies));
      
  if (shouldUpdate) {
    // In order to support react-lifecycles-compat polyfilled components,
    // Unsafe lifecycles should not be invoked for components using the new APIs.
    if (
      !hasNewLifecycles &&
      (typeof instance.UNSAFE_componentWillUpdate === 'function' ||
        typeof instance.componentWillUpdate === 'function')
    ) {
      if (typeof instance.componentWillUpdate === 'function') {
        instance.componentWillUpdate(newProps, newState, nextContext);
      }
      if (typeof instance.UNSAFE_componentWillUpdate === 'function') {
        instance.UNSAFE_componentWillUpdate(newProps, newState, nextContext);
      }
    }
    if (typeof instance.componentDidUpdate === 'function') {
      workInProgress.flags |= Update;
    }
    if (typeof instance.getSnapshotBeforeUpdate === 'function') {
      workInProgress.flags |= Snapshot;
    }
  } else {
    // If an update was already in progress, we should schedule an Update
    // effect even though we're bailing out, so that cWU/cDU are called.
    if (typeof instance.componentDidUpdate === 'function') {
      if (
        unresolvedOldProps !== current.memoizedProps ||
        oldState !== current.memoizedState
      ) {
        workInProgress.flags |= Update;
      }
    }
    if (typeof instance.getSnapshotBeforeUpdate === 'function') {
      if (
        unresolvedOldProps !== current.memoizedProps ||
        oldState !== current.memoizedState
      ) {
        workInProgress.flags |= Snapshot;
      }
    }
    
    // If shouldComponentUpdate returned false, we should still update the
    // memoized props/state to indicate that this work can be reused.
    workInProgress.memoizedProps = newProps;
    workInProgress.memoizedState = newState;
  }
  
  // Update the existing instance's state, props, and context pointers even
  // if shouldComponentUpdate returns false.
  instance.props = newProps;
  instance.state = newState;
  instance.context = nextContext;
  
  return shouldUpdate;
}

Выглядит довольно громоздко, но что поделать? Именно здесь и происходит вся магия жизненного цикла классовых компонентов. Давайте разбираться по порядку.

const unresolvedOldProps = workInProgress.memoizedProps;
const oldProps =
  workInProgress.type === workInProgress.elementType
    ? unresolvedOldProps
    : resolveDefaultProps(workInProgress.type, unresolvedOldProps);
instance.props = oldProps;
const unresolvedNewProps = workInProgress.pendingProps;

Что такое мы уже видели раньше. Суть этого кода получить две константы: unresolvedOldProps, который сразу записывается в this.props экземпляра компонента и unresolvedNewProps. Эти константы далее будут участвовать в методах жизненного цикла и в самой мемоизации в том числе.

const oldContext = instance.context;
const contextType = ctor.contextType;
let nextContext = emptyContextObject;
if (typeof contextType === 'object' && contextType !== null) {
  nextContext = readContext(contextType);
} else if (!disableLegacyContext) {
  const nextUnmaskedContext = getUnmaskedContext(workInProgress, ctor, true);
  nextContext = getMaskedContext(workInProgress, nextUnmaskedContext);
} 

Следующий блок отвечает за резолв привязанного, компоненту, контекста. Подробно эту часть здесь разбираться мы не будем, но переменные oldContext и nextContext участвует в методах жизненного цикла на ряду с unresolvedOldProps и unresolvedNewProps, поэтому обозначить их стоит.

const getDerivedStateFromProps = ctor.getDerivedStateFromProps;
const hasNewLifecycles =
  typeof getDerivedStateFromProps === 'function' ||
  typeof instance.getSnapshotBeforeUpdate === 'function';
  
// Note: During these life-cycles, instance.props/instance.state are what
// ever the previously attempted to render - not the "current". However,
// during componentDidUpdate we pass the "current" props.

// In order to support react-lifecycles-compat polyfilled components,
// Unsafe lifecycles should not be invoked for components using the new APIs.
if (
  !hasNewLifecycles &&
  (typeof instance.UNSAFE_componentWillReceiveProps === 'function' ||
    typeof instance.componentWillReceiveProps === 'function')
) {
  if (
    unresolvedOldProps !== unresolvedNewProps ||
    oldContext !== nextContext
  ) {
    callComponentWillReceiveProps(
      workInProgress,
      instance,
      newProps,
      nextContext,
    );
  }
}

Еще один блок, который я так же не могу оставить без внимания. Прежде чем приступить к следующим этапа жизненного цикла, необходимо сначала выполнить метод componentWillReceiveProps(nextProps), если он был определен в компоненте. А интересно здесь то, что метод будет вызван только в том случае, если компонент не использует новое API, т.е. если в нем нет методов getDerivedStateFromProps(props, state) и getSnapshotBeforeUpdate(prevProps, prevState).

const oldState = workInProgress.memoizedState;
let newState = (instance.state = oldState);
processUpdateQueue(workInProgress, newProps, instance, renderLanes);
newState = workInProgress.memoizedState;

И, наконец четвертый блок. Переменные oldState и newState, которые так же участвуют в жизненном цикле компонента. Здесь остановимся чуть поподробнее. Если с oldState все очевидно, он берется из Fiber.memoizedState, то вот newState требует пояснений.

По умолчанию, newState присваивается значение текущего oldState. Далее исполняется цикл updateQueue, инициированный вызовом processUpdateQueue. Приводить код этой функции здесь не буду, так как он тоже довольно большой и вариативный и только отвлечет нас от темы статьи. Главно, что нам нужно тут понять, что эта функция, в конечно итоге сформирует новый State и запишет его в workInProgress.memoizedState.

/packages/react-reconciler/src/ReactFiberClassUpdateQueue.new.js#L458

export function processUpdateQueue<State>(
  ...
  // These values may change as we process the queue.
  if (firstBaseUpdate !== null) {
    ...
    workInProgress.memoizedState = newState;
  }
}

После чего мы и получаем свою переменную newState нашей update-функции.

На это сбор основной информации о компоненте заканчивается и начинается, собственно, сам процесс обновления.

if (
  unresolvedOldProps === unresolvedNewProps &&
  oldState === newState &&
  !hasContextChanged() &&
  !checkHasForceUpdateAfterProcessing() &&
  !(
    enableLazyContextPropagation &&
    current !== null &&
    current.dependencies !== null &&
    checkIfContextChanged(current.dependencies)
  )
) {
  // If an update was already in progress, we should schedule an Update
  // effect even though we're bailing out, so that cWU/cDU are called.
  if (typeof instance.componentDidUpdate === 'function') {
    if (
      unresolvedOldProps !== current.memoizedProps ||
      oldState !== current.memoizedState
    ) {
      workInProgress.flags |= Update;
    }
  }
  if (typeof instance.getSnapshotBeforeUpdate === 'function') {
    if (
      unresolvedOldProps !== current.memoizedProps ||
      oldState !== current.memoizedState
    ) {
      workInProgress.flags |= Snapshot;
    }
  }
  return false;
}

Нет, это пока еще не обновление, как могло показаться на первый взгляд. Прежде чем к нему приступить, реконсиллер, в целях оптимизации исключает лишние обработки. В данном случае, если ссылки на свойства компонента и на его стейт не изменились и не был вызван forceUpdate(), смысла в дальнейшем процессе просто нет и вся функция завершается.

if (typeof getDerivedStateFromProps === 'function') {
  applyDerivedStateFromProps(
    workInProgress,
    ctor,
    getDerivedStateFromProps,
    newProps,
  );
  newState = workInProgress.memoizedState;
}

Вот теперь, если всё же что-то в состоянии компонента поменялось, можно переходить к его обновлению. И первым, что необходимо сделать, это вызвать getDerivedStateFromProps(props, state), так как этот меняет меняет State компонента и, соответственно, переменную newState в update-функции.

const shouldUpdate =
  checkHasForceUpdateAfterProcessing() ||
  checkShouldComponentUpdate(
    workInProgress,
    ctor,
    oldProps,
    newProps,
    oldState,
    newState,
    nextContext,
  ) ||
  // TODO: In some cases, we'll end up checking if context has changed twice,
  // both before and after `shouldComponentUpdate` has been called. Not ideal,
  // but I'm loath to refactor this function. This only happens for memoized
  // components so it's not that common.
  (enableLazyContextPropagation &&
    current !== null &&
    current.dependencies !== null &&
    checkIfContextChanged(current.dependencies));

Наконец, все константы и переменные собраны и теперь можно принять решение о дальнейшем продвижении по жизненному циклу, точнее, будет ли перерисован компонент. А перерисован компонент должен быть только в двух случаях, если значения свойств, стейта или контекст отличают от предыдущих или если был вызван forceUpdate(). Последнее определяется функцией checkHasForceUpdateAfterProcessing(), а вот сравнение значений происходит внутри checkShouldComponentUpdate(). Остановимся на этой функции поподробнее.

/packages/react-reconciler/src/ReactFiberClassComponent.new.js#L305

function checkShouldComponentUpdate(
  workInProgress,
  ctor,
  oldProps,
  newProps,
  oldState,
  newState,
  nextContext,
) {
  const instance = workInProgress.stateNode;
  if (typeof instance.shouldComponentUpdate === 'function') {
    let shouldUpdate = instance.shouldComponentUpdate(
      newProps,
      newState,
      nextContext,
    );
    ...
    return shouldUpdate;
  }
  
  if (ctor.prototype && ctor.prototype.isPureReactComponent) {
    return (
      !shallowEqual(oldProps, newProps) || !shallowEqual(oldState, newState)
    );
  }
  
  return true;
}

Если убрать из функции служебный dev-mode код, она на удивление довольно простая. Функция предполагает всего три сценария:

1. Компонент имеет метод shouldComponentUpdate(). В этом случае, решение о том, должен ли быть перерисован компонент возлагается полностью на разработчика.
2. В случае PureComponent проводится shallow сравнение свойств и стейта (об это подробнее поговорим чуть ниже).
3. Во всех остальных случаях компонент будет перерисован обязательно.

if (shouldUpdate) {
  // In order to support react-lifecycles-compat polyfilled components,
  // Unsafe lifecycles should not be invoked for components using the new APIs.
  if (
    !hasNewLifecycles &&
    (typeof instance.UNSAFE_componentWillUpdate === 'function' ||
      typeof instance.componentWillUpdate === 'function')
  ) {
    if (typeof instance.componentWillUpdate === 'function') {
      instance.componentWillUpdate(newProps, newState, nextContext);
    }
    if (typeof instance.UNSAFE_componentWillUpdate === 'function') {
      instance.UNSAFE_componentWillUpdate(newProps, newState, nextContext);
    }
  }
  if (typeof instance.componentDidUpdate === 'function') {
    workInProgress.flags |= Update;
  }
  if (typeof instance.getSnapshotBeforeUpdate === 'function') {
    workInProgress.flags |= Snapshot;
  }
} else {
  // If an update was already in progress, we should schedule an Update
  // effect even though we're bailing out, so that cWU/cDU are called.
  if (typeof instance.componentDidUpdate === 'function') {
    if (
      unresolvedOldProps !== current.memoizedProps ||
      oldState !== current.memoizedState
    ) {
      workInProgress.flags |= Update;
    }
  }
  if (typeof instance.getSnapshotBeforeUpdate === 'function') {
    if (
      unresolvedOldProps !== current.memoizedProps ||
      oldState !== current.memoizedState
    ) {
      workInProgress.flags |= Snapshot;
    }
  }
  
  // If shouldComponentUpdate returned false, we should still update the
  // memoized props/state to indicate that this work can be reused.
  workInProgress.memoizedProps = newProps;
  workInProgress.memoizedState = newState;
}

Последним, ну почти последним, этапом является выполнение оставшихся методов жизненного цикла. В случае, если компонент должен быть перерисован, будут выполнены методы:

1. componentWillUpdate (только если не используется новое API)
2. UNSAFE_componentWillUpdate (только если не используется новое API)
3. componentDidUpdate
4. getSnapshotBeforeUpdate

В противном же случае эти методы вызваны не будут, будут проставлены только нужные служебные флаги, а свойства и стейт будут записаны в memoizedProps и memoizedState соответсвенно.

// Update the existing instance's state, props, and context pointers even
// if shouldComponentUpdate returns false.
instance.props = newProps;
instance.state = newState;
instance.context = nextContext;

return shouldUpdate;

И, наконец, последний этап. Новые свойства, стейт и значение контекста присваиваются экземпляру класса, после чего функция завершается.

Поверхностное (shallow) сравнение

Это понятие уже прозвучало чуть выше. Давайте разберем его детальнее. Мы говорили о том, что такое сравнение происходит в случае реализации PureComponent. На всякий случай вспомним, что такое PureComponent. Воспользуемся для этого примером выше и слегка его изменим.

class MyComponent extends React.PureComponent<{ color?: string }> {
  static defaultProps = {
    color: 'blue',
  };
  
  render() {
    return (
      <div>
        {this.props.color}
      </div>
    );
  }
}

Как вы видите, разница только в том, от какого родителя мы наследуем наш классовый компонент (в исходном варианты мы наследовали от React.Component). Именно в таком компоненте и будет применено shallow сравнение.

Так что же такое shallow сравнение? Пожалуй, лучшим ответом на этот вопрос будет код самой функции shallowEqual, которую мы видели ранее.

/packages/shared/shallowEqual.js#L13

/**
 * Performs equality by iterating through keys on an object and returning false
 * when any key has values which are not strictly equal between the arguments.
 * Returns true when the values of all keys are strictly equal.
 */
function shallowEqual(objA: mixed, objB: mixed): boolean {
  if (is(objA, objB)) {
    return true;
  }
  
  if (
    typeof objA !== 'object' ||
    objA === null ||
    typeof objB !== 'object' ||
    objB === null
  ) {
    return false;
  }
  
  const keysA = Object.keys(objA);
  const keysB = Object.keys(objB);
  
  if (keysA.length !== keysB.length) {
    return false;
  }
  
  // Test for A's keys different from B.
  for (let i = 0; i < keysA.length; i++) {
    const currentKey = keysA[i];
    if (
      !hasOwnProperty.call(objB, currentKey) ||
      !is(objA[currentKey], objB[currentKey])
    ) {
      return false;
    }
  }
  
  return true;
}

Эта утилита условно состоит из двух частей:

1. Сравнение переменных objA и objB.
2. Если переменные равны или равны ссылки на объекты, которые они представляют, происходит сравнение каждого из свойств этих объектов.

Само же сравнение осуществляется другой утилитой is().

/packages/shared/objectIs.js#L10

/**
 * inlined Object.is polyfill to avoid requiring consumers ship their own
 * https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is
 */
function is(x: any, y: any) {
  return (
    (x === y && (x !== 0 || 1 / x === 1 / y)) || (x !== x && y !== y) // eslint-disable-line no-self-compare
  );
}

const objectIs: (x: any, y: any) => boolean =
  typeof Object.is === 'function' ? Object.is : is;

Которая является ничем иным, как функцией Web API - Object.is(). В случае, если браузер не поддерживыет данный метод Web API, используется встроенный полифил.

Если коротко, два значения счиются одинаковыми, если:

• оба равны undefined
• оба равны null
• оба равны true, либо оба равны false
• оба являются строками с одинаковой длиной и одинаковыми символами
• оба являются одним и тем же объектом
• оба являются BigInt с одинаковым числовым значением
• оба являются Symbol, которые ссылаются на на один и тот же символ
• оба являются числами и

• оба равны +0
• оба равны -0
• оба равны NaN
• либо оба не равны нулю или NaN и оба имеют одинаковое значение

FunctionComponent

С классовыми компонентами разобрались, давайте посмотрим теперь в функциональные.

const Component = workInProgress.type;
const unresolvedProps = workInProgress.pendingProps;
const resolvedProps =
  workInProgress.elementType === Component
    ? unresolvedProps
    : resolveDefaultProps(Component, unresolvedProps);
return updateFunctionComponent(
  current,
  workInProgress,
  Component,
  resolvedProps,
  renderLanes,
);

В самом начале фазы begin инициация обновления функционального компонента ничем не отличается от обновления классового. За исключением самой update-функции.

/packages/react-reconciler/src/ReactFiberBeginWork.new.js#L965

function updateFunctionComponent(
  current,
  workInProgress,
  Component,
  nextProps: any,
  renderLanes,
) {
  ...
  
  nextChildren = renderWithHooks(
    current,
    workInProgress,
    Component,
    nextProps,
    context,
    renderLanes,
  );
  hasId = checkDidRenderIdHook();

  ...
    
  if (current !== null && !didReceiveUpdate) {
    bailoutHooks(current, workInProgress, renderLanes);
    return bailoutOnAlreadyFinishedWork(current, workInProgress, renderLanes);
  }
  
  if (getIsHydrating() && hasId) {
    pushMaterializedTreeId(workInProgress);
  }
  
  ...
  
  reconcileChildren(current, workInProgress, nextChildren, renderLanes);
  return workInProgress.child;
}

А именно, ключевым здесь является запуск отдельного flow под названием renderWithHooks, характерного для функциональных компонентов. Давайте посмотрим, что там происходит.

/packages/react-reconciler/src/ReactFiberHooks.new.js#L374

export function renderWithHooks<Props, SecondArg>(
  current: Fiber | null,
  workInProgress: Fiber,
  Component: (p: Props, arg: SecondArg) => any,
  props: Props,
  secondArg: SecondArg,
  nextRenderLanes: Lanes,
): any {
  renderLanes = nextRenderLanes;
  currentlyRenderingFiber = workInProgress;
  
  ...
  
  workInProgress.memoizedState = null;
  workInProgress.updateQueue = null;
  workInProgress.lanes = NoLanes;
  
  // The following should have already been reset
  // currentHook = null;
  // workInProgressHook = null;
  
  // didScheduleRenderPhaseUpdate = false;
  // localIdCounter = 0;
  
  // TODO Warn if no hooks are used at all during mount, then some are used during update.
  // Currently we will identify the update render as a mount because memoizedState === null.
  // This is tricky because it's valid for certain types of components (e.g. React.lazy)
  
  // Using memoizedState to differentiate between mount/update only works if at least one stateful hook is used.
  // Non-stateful hooks (e.g. context) don't get added to memoizedState,
  // so memoizedState would be null during updates and mounts.
  ReactCurrentDispatcher.current =
    current === null || current.memoizedState === null
      ? HooksDispatcherOnMount
      : HooksDispatcherOnUpdate;
      
  let children = Component(props, secondArg);
  
  // Check if there was a render phase update
  if (didScheduleRenderPhaseUpdateDuringThisPass) {
    // Keep rendering in a loop for as long as render phase updates continue to
    // be scheduled. Use a counter to prevent infinite loops.
    let numberOfReRenders: number = 0;
    do {
      didScheduleRenderPhaseUpdateDuringThisPass = false;
      localIdCounter = 0;
      
      if (numberOfReRenders >= RE_RENDER_LIMIT) {
        throw new Error(
          'Too many re-renders. React limits the number of renders to prevent ' +
            'an infinite loop.',
        );
      }
      
      numberOfReRenders += 1;
      
      // Start over from the beginning of the list
      currentHook = null;
      workInProgressHook = null;
      
      workInProgress.updateQueue = null;
      
      ReactCurrentDispatcher.current = __DEV__
        ? HooksDispatcherOnRerenderInDEV
        : HooksDispatcherOnRerender;
        
      children = Component(props, secondArg);
    } while (didScheduleRenderPhaseUpdateDuringThisPass);
  }
  
  // We can assume the previous dispatcher is always this one, since we set it
  // at the beginning of the render phase and there's no re-entrance.
  ReactCurrentDispatcher.current = ContextOnlyDispatcher;
  
  // This check uses currentHook so that it works the same in DEV and prod bundles.
  // hookTypesDev could catch more cases (e.g. context) but only in DEV bundles.
  const didRenderTooFewHooks =
    currentHook !== null && currentHook.next !== null;
    
  renderLanes = NoLanes;
  currentlyRenderingFiber = (null: any);
  
  currentHook = null;
  workInProgressHook = null;
  
  didScheduleRenderPhaseUpdate = false;
  // This is reset by checkDidRenderIdHook
  // localIdCounter = 0;
  
  if (didRenderTooFewHooks) {
    throw new Error(
      'Rendered fewer hooks than expected. This may be caused by an accidental ' +
        'early return statement.',
    );
  }
  
  if (enableLazyContextPropagation) {
    if (current !== null) {
      if (!checkIfWorkInProgressReceivedUpdate()) {
        // If there were no changes to props or state, we need to check if there
        // was a context change. We didn't already do this because there's no
        // 1:1 correspondence between dependencies and hooks. Although, because
        // there almost always is in the common case (`readContext` is an
        // internal API), we could compare in there. OTOH, we only hit this case
        // if everything else bails out, so on the whole it might be better to
        // keep the comparison out of the common path.
        const currentDependencies = current.dependencies;
        if (
          currentDependencies !== null &&
          checkIfContextChanged(currentDependencies)
        ) {
          markWorkInProgressReceivedUpdate();
        }
      }
    }
  }
  return children;
}

Функция может показаться большой и сложной, но по сути, она делает всего две вещи. Первое, определяет диспатчер хуков, который будет отвечать за дальнейшее выполнение самих этих хуков. Формально в React существует всего 4 таких диспатчера:

• ContextOnlyDispatcher
• HooksDispatcherOnMount
• HooksDispatcherOnUpdate
• HooksDispatcherOnRender

На самом же деле, ContextOnlyDispatcher не реализует никаких, он является своего рода диспатчером по умолчанию и выставляется до тех пор, пока движок не определил более релевантный диспатчер текущему компоненту.

Из оставшихся трех, HooksDispatcherOnUpdate и HooksDispatcherOnRender на практике ничем не отличаются и оба ведут на одни и те же реализации update-хуков (updateMemo, updateCallback и т.д.). Выделение двух разных диспатчеров здесь носит исключительно логический характер, на случай, если разработчикам React когда-нибудь понадобится сделать разные версии хуков под разные фазы. К в случае в HooksDispatcherOnMount который ведет к отедельным реализациям mount-хуков (mountMemo, mountCallback, и т.д.).

Про хуки и их провайдеры поговорим чуть ниже. Пока зафиксируем только тот факт, что у каждого хука имеется две версии: mount и update. И на текущем этапе важно определить, какую версию хуков движок будет исполнять. Делается следующим образом.

ReactCurrentDispatcher.current =
    current === null || current.memoizedState === null
      ? HooksDispatcherOnMount
      : HooksDispatcherOnUpdate;

Где current - ссылка на Fiber.alternate. Если она равно null, значит компонент еще ни раз не был создан. Аналогично, если Fiber.alternate.memoizedState пустой, то хуки еще в этом компоненте еще ни разу не выполнялись. В обоих случаях будет применен диспатчер HooksDispatcherOnMount. В противном же случае - HooksDispatcherOnUpdate.

Второе, что делает функция - создает компонент посредством let children = Component(props, secondArg) и повторяет этот процесс в цикле, до тех пор, пока в текущей фазе не будут выполнены все запланированные обновления. И да, именно здесь и выбрасывается то самое исключение Too many re-renders. React limits the number of renders to prevent an infinite loop., если количество обновлений превысит 25 итераций.

HooksDispatcherOnMount

Код диспатчера выглядит следующим образом

/packages/react-reconciler/src/ReactFiberHooks.new.js#L2427

const HooksDispatcherOnMount: Dispatcher = {
  readContext,
  
  useCallback: mountCallback,
  useContext: readContext,
  useEffect: mountEffect,
  useImperativeHandle: mountImperativeHandle,
  useLayoutEffect: mountLayoutEffect,
  useInsertionEffect: mountInsertionEffect,
  useMemo: mountMemo,
  useReducer: mountReducer,
  useRef: mountRef,
  useState: mountState,
  useDebugValue: mountDebugValue,
  useDeferredValue: mountDeferredValue,
  useTransition: mountTransition,
  useMutableSource: mountMutableSource,
  useSyncExternalStore: mountSyncExternalStore,
  useId: mountId,
  
  unstable_isNewReconciler: enableNewReconciler,
};
if (enableCache) {
  (HooksDispatcherOnMount: Dispatcher).getCacheSignal = getCacheSignal;
  (HooksDispatcherOnMount: Dispatcher).getCacheForType = getCacheForType;
  (HooksDispatcherOnMount: Dispatcher).useCacheRefresh = mountRefresh;
}

Все mount-функции хуков мы рассматривать не будем, важнее понять суть этих функций. Её и посмотрим на примере mountMemo.

/packages/react-reconciler/src/ReactFiberHooks.new.js#L1899

function mountMemo<T>(
  nextCreate: () => T,
  deps: Array<mixed> | void | null,
): T {
  const hook = mountWorkInProgressHook();
  const nextDeps = deps === undefined ? null : deps;
  const nextValue = nextCreate();
  hook.memoizedState = [nextValue, nextDeps];
  return nextValue;
}

Как можно видеть, код фука до неприличия прост. Сначала определяется ссылка на Fiber. Затем производится вычисление значения, это происходит в пользовательском колбэке nextCreate. Далее, вычисленное значение и массив зависимостей сохраняются в Fiber.memoizedState. Вот она, мемоизация!

HooksDispatcherOnUpdate

Теперь заглянем в диспатчер HooksDispatcherOnUpdate.

/packages/react-reconciler/src/ReactFiberHooks.new.js#L2454

const HooksDispatcherOnUpdate: Dispatcher = {
  readContext,
  
  useCallback: updateCallback,
  useContext: readContext,
  useEffect: updateEffect,
  useImperativeHandle: updateImperativeHandle,
  useInsertionEffect: updateInsertionEffect,
  useLayoutEffect: updateLayoutEffect,
  useMemo: updateMemo,
  useReducer: updateReducer,
  useRef: updateRef,
  useState: updateState,
  useDebugValue: updateDebugValue,
  useDeferredValue: updateDeferredValue,
  useTransition: updateTransition,
  useMutableSource: updateMutableSource,
  useSyncExternalStore: updateSyncExternalStore,
  useId: updateId,
  
  unstable_isNewReconciler: enableNewReconciler,
};
if (enableCache) {
  (HooksDispatcherOnUpdate: Dispatcher).getCacheSignal = getCacheSignal;
  (HooksDispatcherOnUpdate: Dispatcher).getCacheForType = getCacheForType;
  (HooksDispatcherOnUpdate: Dispatcher).useCacheRefresh = updateRefresh;
}

Как я и говорил ранее, этот диспатчер отличается от предыдущего тем, что ведет на update-версии тех же самы хуков. И раз уж в предыдущем примере мы смотрели в mountMemo, в этот раз давайте заглянем в updateMemo.

/packages/react-reconciler/src/ReactFiberHooks.new.js#L1910

function updateMemo<T>(
  nextCreate: () => T,
  deps: Array<mixed> | void | null,
): T {
  const hook = updateWorkInProgressHook();
  const nextDeps = deps === undefined ? null : deps;
  const prevState = hook.memoizedState;
  if (prevState !== null) {
    // Assume these are defined. If they're not, areHookInputsEqual will warn.
    if (nextDeps !== null) {
      const prevDeps: Array<mixed> | null = prevState[1];
      if (areHookInputsEqual(nextDeps, prevDeps)) {
        return prevState[0];
      }
    }
  }
  const nextValue = nextCreate();
  hook.memoizedState = [nextValue, nextDeps];
  return nextValue;
}

А вот тут уже имеет место эффект памяти, который инициировали на этапе монтирования. Теперь, прежде чем приступить к вычислениям, хук возьмет предыдущие зависимости из Fiber.memoizedState[1] и сравнит их с текущими посредством функции areHookInputsEqual(nextDeps, prevDeps).

/packages/react-reconciler/src/ReactFiberHooks.new.js#L327

function areHookInputsEqual(
  nextDeps: Array<mixed>,
  prevDeps: Array<mixed> | null,
) {
  ...
  
  if (prevDeps === null) {
    if (__DEV__) {
      console.error(
        '%s received a final argument during this render, but not during ' +
          'the previous render. Even though the final argument is optional, ' +
          'its type cannot change between renders.',
        currentHookNameInDev,
      );
    }
    return false;
  }
  
  ...
  
  for (let i = 0; i < prevDeps.length && i < nextDeps.length; i++) {
    if (is(nextDeps[i], prevDeps[i])) {
      continue;
    }
    return false;
  }
  return true;
}

Которая в свою очередь, проводит поверхностное сравнение зависимостей с помощью всё того же Object.is.

MemoComponent

Настало время поговорить о третьем интересующим нас типе узла - MemoComponent. Такой узел можно создать с помощью React.memo.

const MyComponent = React.memo<{ color?: string }>(({ color }) => {
  return <div>{color}</div>;
});

Такой компонент будет перерисовываться только в том случае, если изменились переданные ему свойства. Выглядит это следующим образом:

const type = workInProgress.type;
const unresolvedProps = workInProgress.pendingProps;
// Resolve outer props first, then resolve inner props.
let resolvedProps = resolveDefaultProps(type, unresolvedProps);

resolvedProps = resolveDefaultProps(type.type, resolvedProps);
return updateMemoComponent(
  current,
  workInProgress,
  type,
  resolvedProps,
  renderLanes,
);

Update-функция для таких компонентов называется updateMemoComponent. Функция довольно длинная, приведу только ту её часть, которая нам нужна в рамках этой статьи.

/packages/react-reconciler/src/ReactFiberBeginWork.new.js#L452

function updateMemoComponent(
  current: Fiber | null,
  workInProgress: Fiber,
  Component: any,
  nextProps: any,
  renderLanes: Lanes,
): null | Fiber {
  ...
  
  const currentChild = ((current.child: any): Fiber); // This is always exactly one child
  const hasScheduledUpdateOrContext = checkScheduledUpdateOrContext(
    current,
    renderLanes,
  );
  if (!hasScheduledUpdateOrContext) {
    // This will be the props with resolved defaultProps,
    // unlike current.memoizedProps which will be the unresolved ones.
    const prevProps = currentChild.memoizedProps;
    // Default to shallow comparison
    let compare = Component.compare;
    compare = compare !== null ? compare : shallowEqual;
    if (compare(prevProps, nextProps) && current.ref === workInProgress.ref) {
      return bailoutOnAlreadyFinishedWork(current, workInProgress, renderLanes);
    }
  }
  // React DevTools reads this flag.
  workInProgress.flags |= PerformedWork;
  const newChild = createWorkInProgress(currentChild, nextProps);
  newChild.ref = workInProgress.ref;
  newChild.return = workInProgress;
  workInProgress.child = newChild;
  return newChild;
}

Собственно, вся суть этого кода сводится к вызову функции сравнения compare(prevProps, nextProps), где compare может быть как пользовательской функцией (второй аргумент React.memo) или shallowEqual по умолчанию, её мы уже видели выше.

Заключение

В этой статье мы заглянули "под капот" движка React и посмотрели на механизмы монтирования и обновления узлов. Одним из важнейших механизмов React, участвующим в этих процессах является меомизация. Её мы разобрали на примерах трех типов Fiber: ClassComponent, FunctionComponent и MemoComponent.

И покуда мы теперь лучше понимаем эти процессы, самое время сделать некоторые выводы.

• Будь то класс, функция или зависимости хука, React в качестве фукнции-сравнения использует один и тот же подход - метод Object.is() Web API или его полифил.
• Каждый хук имеет две версии реализации, mount и update. При чем update, как правило, более сложная функция, так как ей требуется произвести сравнение зависимостей. Разработчик не можем повлиять на то, какую именно версию хука будет использовать движок. Mount-версия сработает только при первом монтировании компонента.
• Так как React, при обработке хука сравнивает каждую зависимость отдельно, не стоит добавлять лишние зависимости. Кроме того, сами зависимости хранятся в памяти, большое их количество может сказать потреблении ресурсов. Другими словами,

const value = useMemo(() => {
  return a + b
}, [a, b]);

этот код будет чуть более производителен, чем следующий

const value = useMemo(() => {
  return a + b
}, [a, b, c]);

Аналогично,

const SOME_CONST = "some value";

const MyComponent = ({ a, b }) => {
  // этот хук более производителен
  const value1 = useMemo(() => {
    return a + SOME_CONST
  }, [a]);

  // чем этот
  const value2 = useMemo(() => {
    return b + SOME_CONST
  }, [b, SOME_CONST]);  

  return null;
}

• По той же причине стоит адекватно оценивать необходимость в мемоизации в целом, например,

const isEqual = useMemo(() => {
  return a === b
}, [a, b]);

Не даст никакого прироста в производительности. Даже наоборот, движок будет вынужден каждый раз сравнивать prevDeps.a === currDeps.a и prevDeps.b === currDeps.b. К тому же, в коде появляется дополнительная функция, которая будет потреблять свой ресурс.

• Предыдущий тезис касается и React.memo. Разработчик должен понимать, будет ли эффект от мемоизации выше накладных расходов на его её поддержание.

Мои телеграмм-каналы:

English version: https://blog.frontend-almanac.com/react-memoization

Сегодня мы будем говорить об одном из множества механизмов оптимизации, который называется Inline Caches.

Итак, давайте возьмем самую обычную функцию и попробуем понять, как она будет работать в "runtime".

function getX(obj) {
  return obj.x;
}

Наша функция довольно примитивна. Простой геттер, который в качестве аргумента принимает объект, а на выходе возвращает значение свойства x этого объекта. С точки зрения JS-разработчика функция выглядит абсолютно атомарно. Однако, давайте заглянем под капот движка и посмотрим, что она представляет из себя в скомпилированном виде.

Для экспериментов, как обычно, будем использовать самый популярный JS-движок V8 (на момент написания статьи версия 12.6.72). Для полноценного дебага, кроме тела самой функции нам нужна её вызвать с реальным аргументом. Также, добавим вывод информации об объекте, он понадобится нам чуть ниже.

function getX(obj) {
  %DebugPrint(obj);
  return obj.x;
}

getX({ x: 1 });

Напомню, %DebugPrint является строенной функцией V8, чтобы использовать её в коде, нужно запустить рантайм d8 с флагом --allow-natives-syntax. Долнительно, выведем в консоль байткод исполняемого скрипта (флаг --print-bytecode).

%> d8 --print-bytecode --allow-natives-syntax index.js 
...
// байткод функции getX
[generated bytecode for function: getX (0x0b75000d9c29 <SharedFunctionInfo getX>)]
Bytecode length: 10
Parameter count 2
Register count 0
Frame size 0
         0x28c500002194 @    0 : 65 af 01 03 01    CallRuntime [DebugPrint], a0-a0
         0x28c500002199 @    5 : 2d 03 00 00       GetNamedProperty a0, [0], [0]
         0x28c50000219d @    9 : ab                Return
Constant pool (size = 1)
0xb75000d9dcd: [FixedArray] in OldSpace
 - map: 0x0b7500000565 <Map(FIXED_ARRAY_TYPE)>
 - length: 1
           0: 0x0b7500002b91 <String[1]: #x>
Handler Table (size = 0)
Source Position Table (size = 0)
// Далее информация о переданном объекте
DebugPrint: 0xb75001c9475: [JS_OBJECT_TYPE]
 - map: 0x0b75000d9d81 <Map[16](HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x0b75000c4b11 <Object map = 0xb75000c414d>
 - elements: 0x0b75000006cd <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties: 0x0b75000006cd <FixedArray[0]>
 - All own properties (excluding elements): {
    0xb7500002b91: [String] in ReadOnlySpace: #x: 1 (const data field 0), location: in-object
 }
0xb75000d9d81: [Map] in OldSpace
 - map: 0x0b75000c3c29 <MetaMap (0x0b75000c3c79 <NativeContext[285]>)>
 - type: JS_OBJECT_TYPE
 - instance size: 16
 - inobject properties: 1
 - unused property fields: 0
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - back pointer: 0x0b75000d9d59 <Map[16](HOLEY_ELEMENTS)>
 - prototype_validity cell: 0x0b7500000a31 <Cell value= 1>
 - instance descriptors (own) #1: 0x0b75001c9485 <DescriptorArray[1]>
 - prototype: 0x0b75000c4b11 <Object map = 0xb75000c414d>
 - constructor: 0x0b75000c4655 <JSFunction Object (sfi = 0xb7500335385)>
 - dependent code: 0x0b75000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

Итак, в сущности, скомпилированный байткод функции getX выглядит следующим образом.

0x28c500002194 @    0 : 65 af 01 03 01    CallRuntime [DebugPrint], a0-a0
0x28c500002199 @    5 : 2d 03 00 00       GetNamedProperty a0, [0], [0]
0x28c50000219d @    9 : ab                Return

Первая строчка, это вызов функции %DebugPrint. Она носит исключительно вспомогательный характер и на исполняемый код не влияет, мы можем её спокойно опустить. Следующая инструкция GetNamedProperty. Её задача - получить значение указанного свойства из переданного объекта. На вход инструкция получает три параметра. Первый - ссылка на объект. В нашем случае, ссылка на объект хранится в a0 - первом аргументе функции getX. Второй и третий параметры, это адрес скрытого класса и offset нужно свойства в массиве дескрипторов.

Форма объекта

Что такое скрытые классы, массив дескрипторов и как вообще устроены объекты в JavaScript я подробно рассказывал в статье Структура объекта в JavaScript движках. Не буду пересказывать всю статью, обозначу только нужные нам факты. Каждый объект имеет один или несколько скрытых классов (Hidden Classes). Скрытые классы являются исключительно внутренним механизмом движка и JS-разработчику не доступны, ну, по крайней мере, без применения специальных встроенных методов движка. Скрытый класс представляет, так называемую, форму объекта и всю необходимую информацию о свойствах объекта. Сам же объект хранит только значения свойств и ссылку на скрытый класс. Если два объекта имеют одинаковую форму, у них будет ссылка на один и тот же скрытый класс.

const obj1 = { x: 1 }
const obj2 = { x: 2 }

//          {}     <- empty map
//          |
//        { x }    <- common map
//       /    \
// <obj1>      <obj2>

По мере добавления свойств объекту, его дерево скрытых классов увеличивается.

const obj1 = {}
obj1.x = 1;
obj1.y = 2;
obj1.z = 3;

// {} -> { x } -> { x, y } -> { x, y, z } -> <obj1>

Давайте вернемся к функции, с которой мы начали. Предположим, мы передали ей объект следующего вида.

function getX(obj) {
  return obj.x;
}

getX({ y: 1, x: 2, z: 3 });

Что получить значение свойства x, интерпретатор должен знать: а) адрес последнего скрытого класса объекта; б) offset этого свойства в массиве десктрипторов.

d8> const obj = { y: 1, x: 2, z: 3};
d8>
d8> %DebugPrint(obj);
DebugPrint: 0x2034001c9435: [JS_OBJECT_TYPE]
 - map: 0x2034000d9cf9 <Map[24](HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x2034000c4b11 <Object map = 0x2034000c414d>
 - elements: 0x2034000006cd <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties: 0x2034000006cd <FixedArray[0]>
 - All own properties (excluding elements): {
    0x203400002ba1: [String] in ReadOnlySpace: #y: 1 (const data field 0), location: in-object
    0x203400002b91: [String] in ReadOnlySpace: #x: 2 (const data field 1), location: in-object
    0x203400002bb1: [String] in ReadOnlySpace: #z: 3 (const data field 2), location: in-object
 }
0x2034000d9cf9: [Map] in OldSpace
 - map: 0x2034000c3c29 <MetaMap (0x2034000c3c79 <NativeContext[285]>)>
 - type: JS_OBJECT_TYPE
 - instance size: 24
 - inobject properties: 3
 - unused property fields: 0
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - back pointer: 0x2034000d9cd1 <Map[24](HOLEY_ELEMENTS)>
 - prototype_validity cell: 0x203400000a31 <Cell value= 1>
 - instance descriptors (own) #3: 0x2034001c9491 <DescriptorArray[3]>
 - prototype: 0x2034000c4b11 <Object map = 0x2034000c414d>
 - constructor: 0x2034000c4655 <JSFunction Object (sfi = 0x203400335385)>
 - dependent code: 0x2034000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

В примере выше скрытый класс расположен по адресу 0x2034000d9cd1 (back pointer).

d8> %DebugPrintPtr(0x2034000d9cd1)
DebugPrint: 0x2034000d9cd1: [Map] in OldSpace
 - map: 0x2034000c3c29 <MetaMap (0x2034000c3c79 <NativeContext[285]>)>
 - type: JS_OBJECT_TYPE
 - instance size: 24
 - inobject properties: 3
 - unused property fields: 1
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - back pointer: 0x2034000d9c89 <Map[24](HOLEY_ELEMENTS)>
 - prototype_validity cell: 0x203400000a31 <Cell value= 1>
 - instance descriptors #2: 0x2034001c9491 <DescriptorArray[3]>
 - transitions #1: 0x2034000d9cf9 <Map[24](HOLEY_ELEMENTS)>
     0x203400002bb1: [String] in ReadOnlySpace: #z: (transition to (const data field, attrs: [WEC]) @ Any) -> 0x2034000d9cf9 <Map[24](HOLEY_ELEMENTS)>
 - prototype: 0x2034000c4b11 <Object map = 0x2034000c414d>
 - constructor: 0x2034000c4655 <JSFunction Object (sfi = 0x203400335385)>
 - dependent code: 0x2034000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0
0x2034000c3c29: [MetaMap] in OldSpace
 - map: 0x2034000c3c29 <MetaMap (0x2034000c3c79 <NativeContext[285]>)>
 - type: MAP_TYPE
 - instance size: 40
 - native_context: 0x2034000c3c79 <NativeContext[285]>

Из которого мы можем получить массив дескрипторов по адресу 0x2034001c9491 (instance descriptors).

d8> %DebugPrintPtr(0x2034001c9491)
DebugPrint: 0x2034001c9491: [DescriptorArray]
 - map: 0x20340000062d <Map(DESCRIPTOR_ARRAY_TYPE)>
 - enum_cache: 3
   - keys: 0x2034000daaa9 <FixedArray[3]>
   - indices: 0x2034000daabd <FixedArray[3]>
 - nof slack descriptors: 0
 - nof descriptors: 3
 - raw gc state: mc epoch 0, marked 0, delta 0
  [0]: 0x203400002ba1: [String] in ReadOnlySpace: #y (const data field 0:s, p: 2, attrs: [WEC]) @ Any
  [1]: 0x203400002b91: [String] in ReadOnlySpace: #x (const data field 1:s, p: 1, attrs: [WEC]) @ Any
  [2]: 0x203400002bb1: [String] in ReadOnlySpace: #z (const data field 2:s, p: 0, attrs: [WEC]) @ Any
0x20340000062d: [Map] in ReadOnlySpace
 - map: 0x2034000004c5 <MetaMap (0x20340000007d <null>)>
 - type: DESCRIPTOR_ARRAY_TYPE
 - instance size: variable
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - non-extensible
 - back pointer: 0x203400000061 <undefined>
 - prototype_validity cell: 0
 - instance descriptors (own) #0: 0x203400000701 <DescriptorArray[0]>
 - prototype: 0x20340000007d <null>
 - constructor: 0x20340000007d <null>
 - dependent code: 0x2034000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

Где интерпретатор может найти нужное свойство по его имени и получить offset, в нашем случае равный 1.

Таким образом, путь интерпретатора будет выглядеть примерно следующим образом.

Наш случай довольно простой. Здесь значения свойств хранятся внутри самого объекта (in-object), что делает доступ к ним довольно быстрым. Но, тем не менее, определение позиции свойства в массиве дескрипторов все равно будет пропорционально количеству самих свойств. Более того, в статье Структура объекта в JavaScript движках я говорил, что значения не всегда хранятся таким "быстрым" образом. В ряде случаев тип хранилища может быть изменен на медленный "словарь".

Inline Cache

Конечно, в единичных случаях для JS-движка это все не вызывает больших трудностей, а время доступа к значению свойств вряд ли можно заметить невооруженным глазом. Но что, если наш случай не единичный? Допустим, нам требуется выполнить функцию сотни или тысячи раз в цикле? Суммарное время работы тут приобретает критическую важность. При том, что функция, фактически выполняет одни и те же операции, разработчики JavaScript предложили оптимизировать процесс поиска свойства и не выполнять его каждый раз. Все, что для этого требуется, сохранить адрес скрытого класса объекта и offset нужного свойства.

Вернемся к самому началу статьи и к инструкции GetNamedProperty, которая имеет три параметра. Мы уже выяснили, что первый параметр - это ссылка на объект. Второй параметр - адрес скрытого класса. Третий параметр - найденный offset свойства. Определив эти параметры единожды, функция может их запомнить и при следующем запуске не выполнять процедуру поиска значения снова. Такое кэширование и называется Inline Cache (IC).

TurboFan

Однако, стоит учитывать, что мемоизация параметров тоже требует памяти и некоторого процессорного времени. Это делает механизм эффективным только при интенсивном выполнении функции (так называемая, hot-функция). Насколько интенсивно выполняется функция зависит от количества и частоты её вызовов. Оценкой интенсивности занимается оптимизатор. В случае с V8 в роли оптимизатора выступает TurboFan. Прежде всего, оптимизатор собирает граф из AST и байткода и отправляет его на фазу "inlining", где собираются метрики вызовов, загрузок и сохранений в кэш. Далее, если функция пригодна для inline-кэширования, она встает в очередь на оптимизацию. После того как очередь заполнена оптимизатор должен определить самую "горячую" из них и произвести кэширование. Потом взять следующую и так далее. В отличие, кстати, от его предшественника Crankshaft, который брал функции по очереди начиная с первой. Вообще, данная тема довольно большая и заслуживает отдельной статьи, сейчас рассматривать все подробности и особенности эвристики TurboFan смысла не имеет . Перейдем лучше к примерам.

Типы IC

Чтобы проанализировать работу IC, нужно включить логирование в runtime-среде. В случае с d8 это можно сделать, указав флаг --log-ic.

%> d8 --log-ic

function getX(obj) {
  return obj.x;
}

for (let i = 0; i < 10; i++) {
  getX({ x: i });
}

Как я уже говорил, TurboFan начинает кэшировать свойства объектов только в hot-функциях. Чтобы сделать нашу функцию таковой, нам потребуется запустить её в цикле несколько раз подряд. В моем простом скрипте в среде d8 понадобилось минимум 10 итераций. На практике, в других условиях и при наличии других функций, это число может варьироваться и, скорее всего, будет больше. Полученный лог теперь можно прогнать через System Analyzer.

Grouped by type: 1#
>100.00%	1	LoadIC
Grouped by category: 1#
>100.00%	1	Load
Grouped by functionName: 1#
>100.00%	1	~getX
Grouped by script: 1#
>100.00%	1	Script(3): index.js
Grouped by sourcePosition: 1#
>100.00%	1	index.js:3:14
Grouped by code: 1#
>100.00%	1	Code(JS~)
Grouped by state: 1#
>100.00%	1	0 → 1
Grouped by key: 1#
>100.00%	1	x
Grouped by map: 1#
>100.00%	1	Map(0x3cd2000d9e61)
Grouped by reason: 1#
>100.00%	1	

В списке IC List мы видим нотацию типа LoadIC, которая говорит о получении доступа к свойству объекта из кэша. Здесь же указана сама функция functionName: ~getX, адрес скрытого класса Map(0x3cd2000d9e61) и название свойства key: x. Но наибольший интерес представляет state: 0 -> 1.

Существует несколько типов IC. Полный список выглядит следующим образом:

/src/common/globals.h#1481

// State for inline cache call sites. Aliased as IC::State.
enum class InlineCacheState {
  // No feedback will be collected.
  NO_FEEDBACK,
  // Has never been executed.
  UNINITIALIZED,
  // Has been executed and only one receiver type has been seen.
  MONOMORPHIC,
  // Check failed due to prototype (or map deprecation).
  RECOMPUTE_HANDLER,
  // Multiple receiver types have been seen.
  POLYMORPHIC,
  // Many DOM receiver types have been seen for the same accessor.
  MEGADOM,
  // Many receiver types have been seen.
  MEGAMORPHIC,
  // A generic handler is installed and no extra typefeedback is recorded.
  GENERIC,
};

В системном анализаторе эти типы обозначаются символами

0: UNINITIALIZED
X: NO_FEEDBACK
1: MONOMORPHIC
^: RECOMPUTE_HANDLER
P: POLYMORPHIC
N: MEGAMORPHIC
D: MEGADOM
G: GENERIC

Например, тип X (NO_FEEDBACK) говорит о тои, что оптимизатор пока не собрал достаточной статистики, чтобы поставить функцию на оптимизацию. В нашем же случае мы видим state: 0 -> 1 означает, что функция перешла в состояние "мономорфного IC".

Monomorphic

Я уже говорил, что на практике, одна и та же функция может принимать объект в качестве аргумента. Форма этого объекта на конкретном вызове функции может отличаться от предыдущего. Что несколько усложняет жизнь оптимизатору. Меньше всего проблем возникает в случае, когда мы передаем в функцию только одинаковый по форме объекты, как в нашем последнем примере.

function getX(obj) {
  return obj.x; // Monomorphic IC
}

for (let i = 0; i < 10; i++) {
  getX({ x: i }); // все объекты имеют одинаковую форму
}

В этом случае, оптимизатору надо просто запомнить адрес скрытого класса и offset свойства. Такой тип IC называется мономорфным.

Polymorphic

Давайте теперь попробуем добавить вызов функции с объектами разной формы.

function getX(obj) {
  return obj.x; // Polymorphic IC
}

for (let i = 0; i < 10; i++) {
  getX({ x: i, y: 0 });
  getX({ y: 0, x: i });
}

В "IC List" теперь мы видим:

50.00%        1    0 → 1
50.00%        1    1 → P

Функция в рантайме получила несколько разных форм объекта. Доступ к свойству x у каждой формы будет отличаться. У каждой свой адрес скрытого класса и свой offset этого свойства. В этом, случае оптимизатор выделяет по два слота для каждой формы объекта, куда и сохраняет нужные параметры. Условно представить такую структура можно в виде массива наборов параметров.

[
  [Map1, offset1],
  [Map2, offset2],
  ...
]

Такой тип IC называется полиморфным. У полиморфного IC есть ограничение на количество допустимых форм.

/src/wasm/wasm-constants.h#192

// Maximum number of call targets tracked per call.
constexpr int kMaxPolymorphism = 4;

По умолчанию, полиморфный тип может от 2 до 4 форм на функцию. Но этот параметр можно регулировать флагом --max-valid-polymorphic-map-count.

Megamorphic

Если же форм объекта больше, чем может переварит Polymorphic, тип меняется на мегаморфный.

function getX(obj) {
  return obj.x; // Megamorphic IC
}

for (let i = 0; i < 10; i++) {
  getX({ x: i });
  getX({ prop1: 0, x: i });
  getX({ prop1: 0, prop2: 1, x: i });
  getX({ prop1: 0, prop2: 1, prop3: 2, x: i });
  getX({ prop1: 0, prop2: 1, prop3: 2, prop4: 3, x: i });
}

Результат IC List:

40.00%        2    P → P
20.00%        1    0 → 1
20.00%        1    1 → P
20.00%        1    P → N

Поиск нужного набора параметров в таком случае нивелирует экономию процессорного времени и, следовательно, не имеет никакого смысла. Поэтому оптимизатор просто сохраняет в кэш символ MegamorphicSymbol. Для следующих вызовов фукнции это будет означать, что закэшированных параметров тут нет, их придется брать обычным способом. Равно как и нет смысла дальше ставить функцию на оптимизацию и собирать её метрики.

Заключение

Вы наверняка заметили, что в списке типов IC присутствует еще MEGADOM. Этот тип используется для кэширования нод DOM-дерева. Дело в том, что механизм инлайн-кэширования не ограничивается только функциями и объектами. Он активно применяется и во многих других местах, в том числе и за пределами V8.Ввесь объем информации о кэшировании за один раз мы физически покрыть не сможем. А раз уж мы сегодня говорим об объектах JavaScript, то и тип MegaDom рассматривать в этой статье не будем.

Давайте проведем пару тестов и посмотрим, на сколько эффективно работает оптимизация Turbofan в V8. Эксперимент будем ставить в среде Node.js (последняя стабильная версия на момент написания статьи v20.12.2).

Экспериментальный код:

const N = 1000;

//===

function getXMonomorphic(obj) {
  let sum = 0;

  for (let i = 0; i < N; i++) {
    sum += obj.x;
  }

  return sum;
}

console.time('Monomorphic');

for (let i = 0; i < N; i++) {
  getXMonomorphic({ x: i });
  getXMonomorphic({ x: i });
  getXMonomorphic({ x: i });
  getXMonomorphic({ x: i });
  getXMonomorphic({ x: i });
}

console.timeLog('Monomorphic');

//===

function getXPolymorphic(obj) {
  let sum = 0;

  for (let i = 0; i < N; i++) {
    sum += obj.x;
  }

  return sum;
}

console.time('Polymorphic');

for (let i = 0; i < N; i++) {
  getXPolymorphic({ x: i, y: 0 });
  getXPolymorphic({ y: 0, x: i });
  getXPolymorphic({ x: i, y: 0 });
  getXPolymorphic({ y: 0, x: i });
  getXPolymorphic({ x: i, y: 0 });
}

console.timeEnd('Polymorphic');

//===

function getXMegamorphic(obj) {
  let sum = 0;

  for (let i = 0; i < N; i++) {
    sum += obj.x;
  }

  return sum;
}

//===

console.time('Megamorphic');

for (let i = 0; i < N; i++) {
  getXMegamorphic({ x: i });
  getXMegamorphic({ prop1: 0, x: i });
  getXMegamorphic({ prop1: 0, prop2: 1, x: i });
  getXMegamorphic({ prop1: 0, prop2: 1, prop3: 2, x: i });
  getXMegamorphic({ prop1: 0, prop2: 1, prop3: 2, prop4: 3, x: i });
}

console.timeLog('Megamorphic');

Для начала запустим скрипт с отключенной оптимизацией и посмотрим "чистую" скорость работы функций.

%> node --no-opt test.js
Monomorphic: 68.55ms
Polymorphic: 69.939ms
Megamorphic: 85.045ms

Для чистоты эксперимента я повторил тесты несколько раз. Скорость работы мономорфных и полиморфных объектов примерно одинакова. Полиморфные иногда могу оказываться даже быстрее. Связано это уже не столько с работой самого V8, сколько с системными ресурсами. А вот скорость мегаморфных объектов несколько ниже в силу того, что на этом тапе образуется дерево скрытых классов и доступ к свойствам этих объектов априори сложнее, чем в первых двух случаях.

Теперь запустим тот же скрипт с включенной оптимизацией:

%> node test.js
Monomorphic: 9.313ms
Polymorphic: 9.673ms
Megamorphic: 29.104ms

Скорость работы мономорфных и полиморфных функций увеличилась примерно в 7 раз. Как и в предыдущем случае, разница между этими двумя типами незначительна и при повторных испытаниях полиморфные иногда бывают даже быстрее. А вот скорость мегаморфной функции увеличилась всего в 3 раза. Вообще, исходя из теории, описанной выше, мегаморфные функции не должны были показать прирост скорости на оптимизации. Однако, не все так просто. Во-первых, у них все же имеется побочный эффект от оптимизации, поскольку такие функции исключаются из процесса дальнейшего сбора метрик. Это хоть и не большое, но все же преимущество перед остальными типами. Во-вторых, оптимизация работы JS не ограничена инлайн-кэшированием доступа к свойствам объекта. Существует еще ряд других видов оптимизаций, которые в этой статье мы не рассматривали.

Более того, в 2023-м году Google выпустил релиз "Chromium M117", в который был включен новый оптимизатор Maglev. Он был встроен как промежуточное звено между Ignition (интерпретатором) и Turbofan (оптимизатором). Теперь процесс оптимизации приобрел трех-ступенчатую архитектуру и выглядит как Ignition -> Maglev -> Turbofan. Maglev вносит свой вклад в оптимизацию функций, в частности, он работает с аргументами функции. Подробнее об этом поговорим в другой раз. А пока можем сделать вывод, что мегаморфные функции примерно в два раза медленнее мономорфных и полиморфных.

Мои телеграмм-каналы:

English version: https://blog.frontend-almanac.com/js-optimisation-ic

Объект и его свойства

Прежде чем погрузиться во внутренние структуры объекта, давайте быстро пройдемся по мат. части и вспомним, что вообще представляет собой объект. Спецификация ECMA-262 в разделе 6.1.7 The Object Type определяет объект довольно примитивно, просто как набор свойств. Свойства объекта представлены как структура "ключ-значение", где ключ (key) является названием свойства, а значение (value) - набором атрибутов. Все свойства объекта можно условно разделить на два типа: data properties и accessor properties.

Data properties

Свойства, имеющие следующие атрибуты:

• [[Value]] - значение свойства
• [[Writable]] - boolean, по умолчанию false - если false, значение [[Value]] не может быть изменено
• [[Enumerable]] - boolean, по умолчанию false - если true, свойство может участвовать в итерировании посредством "for-in"
• [[Configurable]] - boolean, по умолчанию false - если false, свойство не может быть удалено, нельзя изменить его тип с Data property на Accessor property (и наоборот), нельзя изменить никакие атрибуты, кроме [[Value]] и выставления [[Writable]] в false

Accessor properties

Свойства, имеющие следующие атрибуты:

• [[Get]] - функция, возвращающая значение объекта
• [[Set]] - функция, вызываемая при попытке присвоить значение свойству
• [[Enumerable]] - идентичен Data property
• [[Configurable]] - идентичен Data property

Скрытые классы

Таким образом, согласно спецификации, помимо самих значений, каждое свойство объекта должно хранить информацию о своих атрибутах.

const obj1 = { a: 1, b: 2 };

Приведенный выше простой объект, в представлении движка JavaScript, должен выглядеть примерно следующим образом.

{
  a: {
    [[Value]]: 1,
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  },
  b: {
    [[Value]]: 2,
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  }
}

Давайте теперь представим, что у нас есть два схожих по структуре объекта.

const obj1 = { a: 1, b: 2 };
const obj2 = { a: 3, b: 4 };

Согласно вышесказанному, нам нужно хранить информацию о каждом из четырех приведенных свойств этих двух объектов. Звучит несколько расточительно с точки зрения потребления памяти. Кроме того, очевидно, что конфигурация этих свойств одинакова, за исключением названия свойства и его [[Value]].

Данную проблему все популярные JS-движки решают с помощью так называемых скрытых классов (hidden classes). Это понятие часто можно встретить в разного рода публикациях и документации. Однако оно немного пересекается с понятием JavaScript-классов, поэтому разработчики движков приняли свои собственные определения. Так, в V8 скрытые классы обозначаются термином Maps (что также пересекается с понятием JavaScript Maps). В движке Chakra, используемом в браузере Internet Explorer, применяется термин Types. Разработчики Safari, в своем движке JavaScriptCore, используют понятие Structures. А в движке SpiderMonkey для Mozilla скрытые классы называются Shapes. Последнее, кстати, тоже довольно популярно и не редко встречается в публикациях, так как это понятие уникально и его трудно перепутать с чем-либо другим в JavaScript.

Вообще, про скрытые классы в сети есть много интересных публикаций. В частности, рекомендую заглянуть в пост Матиаса Биненса, одного из разработчиков V8 и Chrome DevTools.

Итак, суть скрытых классов заключается в том, чтобы выделить метаинформацию и свойства объекта в отдельные, переиспользуемые объекты и привязывать такой класс к реальному объекту по ссылке.

В данной концепции пример выше можно представить следующим образом. Позже мы посмотрим, как выглядят реальные Maps в движке V8, а пока проиллюстрирую в условном виде.

Map1 {
  a: {
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  },
  b: {
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  }
}

ob1 {
  map: Map1,
  values: { a: 1, a: 2 }
}

ob2 {
  map: Map1,
  values: { a: 3, a: 4 }
}

Наследование скрытого класса

Концепция скрытых классов выглядит неплохо в случае объектов с одинаковой формой. Однако, что делать, если второй объект имеет другую структуру? В следующем примере два объекта не идентичны друг другу по структуре, но имеют пересечение.

const obj1 = { a: 1, b: 2 };
const obj2 = { a: 3, b: 4, c: 5 };

По описанной выше логике в памяти должно появиться два класса с разной формой. Однако тогда проблема дублирования атрибутов возвращается. Дабы избежать этого, скрытые классы принято наследовать друг от друга.

Map1 {
  a: {
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  },
  b: {
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  }
}

Map2 {
  back_pointer: Map1,
  с: {
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  }
}

ob1 {
  map: Map1,
  values: { a: 1, b: 2 }
}

ob2 {
  map: Map2,
  values: { a: 3, b: 4, c: 5 }
}

Здесь мы видим, что класс Map2 описывает только одно свойство и ссылку на объект с более "узкой" формой.

Стоит также сказать, что на форму скрытого класса влияет не только набор свойств, но и их порядок. Другими словами, следующие объекты будут иметь разные формы скрытых классов.

Map1 {
  a: {
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  },
  b: {
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  }
}

Map2 {
  b: {
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  },
  a: {
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  }
}

ob1 {
  map: Map1,
  values: { a: 1, b: 2 }
}

ob2 {
  map: Map2,
  values: { b: 3, a: 4 }
}

Если мы меняем форму объекта уже после инициализации, это также приводит к созданию нового скрытого класса-наследника.

const ob1 = { a: 1, b: 2 };
obj1.c = 3;

const obj2 = { a: 4, b: 5, c: 6 };

Данный пример приводит к следующей структуре скрытых классов.

Map1 {
  a: {
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  },
  b: {
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  }
}

Map2 {
  back_pointer: Map1,
  с: {
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  }
}

Map3 {
  back_pointer: Map1,
  с: {
    [[Writable]]: true,
    [[Enumerable]]: true,
    [[Configurable]]: true,
  }
}

ob1 {
  map: Map2,
  values: { a: 1, b: 2, c: 3 }
}

ob2 {
  map: Map3,
  values: { a: 4, b: 5, c: 6 }
}

Скрытые классы на практике

Чуть выше я ссылался на пост Матиаса Биненса о формах объекта. Однако с тех пор прошло много лет. Для чистоты эксперимента я решил проверить, как обстоят дела на практике в реальном движке V8.

Проведем эксперимент на примере, приведенном в статье Матиаса.

Для этого нам понадобится встроенный внутренний методом V8 - %DebugPrint. Напомню, чтобы иметь возможность использовать встроенные методы движка, его нужно запустить с флагом --allow-natives-syntax. Чтобы видеть подробную информацию об объектах JS, движок должен быть скомпилирован в режиме debug.

d8> const a = {};
d8> a.x = 6;
d8> const b = { x: 6 };
d8>
d8> %DebugPrint(a);
DebugPrint: 0x1d47001c9425: [JS_OBJECT_TYPE]
 - map: 0x1d47000da9a9 <Map[28](HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x1d47000c4b11 <Object map = 0x1d47000c414d>
 - elements: 0x1d47000006cd <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties: 0x1d47000006cd <FixedArray[0]>
 - All own properties (excluding elements): {
    0x1d4700002b91: [String] in ReadOnlySpace: #x: 6 (const data field 0), location: in-object
 }
0x1d47000da9a9: [Map] in OldSpace
 - map: 0x1d47000c3c29 <MetaMap (0x1d47000c3c79 <NativeContext[285]>)>
 - type: JS_OBJECT_TYPE
 - instance size: 28
 - inobject properties: 4
 - unused property fields: 3
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - back pointer: 0x1d47000c4945 <Map[28](HOLEY_ELEMENTS)>
 - prototype_validity cell: 0x1d47000da9f1 <Cell value= 0>
 - instance descriptors (own) #1: 0x1d47001cb111 <DescriptorArray[1]>
 - prototype: 0x1d47000c4b11 <Object map = 0x1d47000c414d>
 - constructor: 0x1d47000c4655 <JSFunction Object (sfi = 0x1d4700335385)>
 - dependent code: 0x1d47000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

Мы видим объект a, размещенный по адресу 0x1d47001c9425. К объекту привязан скрытый класс с адресом 0x1d47000da9a9. Внутри самого объекта хранится значение #x: 6. Атрибуты свойства расположены в привязанном скрытом классе в поле instance descriptors. На всякий случай, давайте посмотрим на массив дескрипторов по указанному адресу.

d8> %DebugPrintPtr(0x1d47001cb111)
DebugPrint: 0x1d47001cb111: [DescriptorArray]
 - map: 0x1d470000062d <Map(DESCRIPTOR_ARRAY_TYPE)>
 - enum_cache: 1
   - keys: 0x1d47000dacad <FixedArray[1]>
   - indices: 0x1d47000dacb9 <FixedArray[1]>
 - nof slack descriptors: 0
 - nof descriptors: 1
 - raw gc state: mc epoch 0, marked 0, delta 0
  [0]: 0x1d4700002b91: [String] in ReadOnlySpace: #x (const data field 0:s, p: 0, attrs: [WEC]) @ Any
0x1d470000062d: [Map] in ReadOnlySpace
 - map: 0x1d47000004c5 <MetaMap (0x1d470000007d <null>)>
 - type: DESCRIPTOR_ARRAY_TYPE
 - instance size: variable
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - non-extensible
 - back pointer: 0x1d4700000061 <undefined>
 - prototype_validity cell: 0
 - instance descriptors (own) #0: 0x1d4700000701 <DescriptorArray[0]>
 - prototype: 0x1d470000007d <null>
 - constructor: 0x1d470000007d <null>
 - dependent code: 0x1d47000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

32190781763857

В массиве дескрипторов имеется элемент #x, который хранит всю необходимую информацию о свойстве объекта.

Теперь давайте посмотрим на ссылку back pointer с адресом 0x1d47000c4945.

d8> %DebugPrintPtr(0x1d47000c4945)
DebugPrint: 0x1d47000c4945: [Map] in OldSpace
 - map: 0x1d47000c3c29 <MetaMap (0x1d47000c3c79 <NativeContext[285]>)>
 - type: JS_OBJECT_TYPE
 - instance size: 28
 - inobject properties: 4
 - unused property fields: 4
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - back pointer: 0x1d4700000061 <undefined>
 - prototype_validity cell: 0x1d4700000a31 <Cell value= 1>
 - instance descriptors (own) #0: 0x1d4700000701 <DescriptorArray[0]>
 - transitions #1: 0x1d47000da9d1 <TransitionArray[6]>Transition array #1:
     0x1d4700002b91: [String] in ReadOnlySpace: #x: (transition to (const data field, attrs: [WEC]) @ Any) -> 0x1d47000da9a9 <Map[28](HOLEY_ELEMENTS)>

 - prototype: 0x1d47000c4b11 <Object map = 0x1d47000c414d>
 - constructor: 0x1d47000c4655 <JSFunction Object (sfi = 0x1d4700335385)>
 - dependent code: 0x1d47000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0
0x1d47000c3c29: [MetaMap] in OldSpace
 - map: 0x1d47000c3c29 <MetaMap (0x1d47000c3c79 <NativeContext[285]>)>
 - type: MAP_TYPE
 - instance size: 40
 - native_context: 0x1d47000c3c79 <NativeContext[285]>

32190780688709

Этот скрытый класс является представлением пустого объекта. Массив дескрипторов у него пустой, а ссылка back pointer не определена.

Теперь давайте посмотрим на объект b.

d8> %DebugPrint(b)    
DebugPrint: 0x1d47001cb169: [JS_OBJECT_TYPE]
 - map: 0x1d47000dab39 <Map[16](HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x1d47000c4b11 <Object map = 0x1d47000c414d>
 - elements: 0x1d47000006cd <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties: 0x1d47000006cd <FixedArray[0]>
 - All own properties (excluding elements): {
    0x1d4700002b91: [String] in ReadOnlySpace: #x: 6 (const data field 0), location: in-object
 }
0x1d47000dab39: [Map] in OldSpace
 - map: 0x1d47000c3c29 <MetaMap (0x1d47000c3c79 <NativeContext[285]>)>
 - type: JS_OBJECT_TYPE
 - instance size: 16
 - inobject properties: 1
 - unused property fields: 0
 - elements kind: HOLEY_ELEMENTS
 - enum length: 1
 - stable_map
 - back pointer: 0x1d47000dab11 <Map[16](HOLEY_ELEMENTS)>
 - prototype_validity cell: 0x1d4700000a31 <Cell value= 1>
 - instance descriptors (own) #1: 0x1d47001cb179 <DescriptorArray[1]>
 - prototype: 0x1d47000c4b11 <Object map = 0x1d47000c414d>
 - constructor: 0x1d47000c4655 <JSFunction Object (sfi = 0x1d4700335385)>
 - dependent code: 0x1d47000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

{x: 6}

Здесь также значение свойства хранится в самом объекте, а атрибуты свойства — в массиве дескрипторов скрытого класса. Однако обращу внимание, что ссылка back pointer здесь тоже не пустая, хотя на приведенной схеме класса-родителя тут быть не должно. Давайте посмотрим на класс по этой ссылке.

d8> %DebugPrintPtr(0x1d47000dab11)
DebugPrint: 0x1d47000dab11: [Map] in OldSpace
 - map: 0x1d47000c3c29 <MetaMap (0x1d47000c3c79 <NativeContext[285]>)>
 - type: JS_OBJECT_TYPE
 - instance size: 16
 - inobject properties: 1
 - unused property fields: 1
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - back pointer: 0x1d4700000061 <undefined>
 - prototype_validity cell: 0x1d4700000a31 <Cell value= 1>
 - instance descriptors (own) #0: 0x1d4700000701 <DescriptorArray[0]>
 - transitions #1: 0x1d47000dab39 <Map[16](HOLEY_ELEMENTS)>
     0x1d4700002b91: [String] in ReadOnlySpace: #x: (transition to (const data field, attrs: [WEC]) @ Any) -> 0x1d47000dab39 <Map[16](HOLEY_ELEMENTS)>
 - prototype: 0x1d47000c4b11 <Object map = 0x1d47000c414d>
 - constructor: 0x1d47000c4655 <JSFunction Object (sfi = 0x1d4700335385)>
 - dependent code: 0x1d47000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0
0x1d47000c3c29: [MetaMap] in OldSpace
 - map: 0x1d47000c3c29 <MetaMap (0x1d47000c3c79 <NativeContext[285]>)>
 - type: MAP_TYPE
 - instance size: 40
 - native_context: 0x1d47000c3c79 <NativeContext[285]>

32190780779281

Класс выглядит точно так же, как скрытый класс пустого объекта выше, но с другим адресом. Это означает, что фактически это дубликат предыдущего класса. Таким образом, реальная структура данного примера выглядит следующим образом.

Это первое отклонение от теории. Чтобы понять, зачем нужен еще один скрытый класс для пустого объекта, нам потребуется объект с несколькими свойствами. Предположим, что исходный объект изначально имеет несколько свойств. Исследовать такой объект через командную строку будет не очень удобно, поэтому воспользуемся Chrome DevTools. Для удобства, замкнем объект внутри контекста функции.

function V8Snapshot() {
  this.obj1 = { a: 1, b: 2, c: 3, d: 4, e: 5, f: 6 };
}

const v8Snapshot1 = new V8Snapshot();

Слепок памяти показывает 6 наследуемых классов для этого объекта, что равно количеству свойств объекта. И это второе отклонение от теории, согласно которой предполагалось, что объект изначально имеет один скрытый класс, форма которого содержит те свойства, с которыми он был инициализирован. Причина этому кроется в том, что на практике мы оперируем не одним единственным объектом, а несколькими, может быть даже десятками, сотнями или тысячами. В таких реалиях поиск и перестройка деревьев классов могут оказаться весьма дорогими. Итак, мы подошли к еще одному понятию JS движков.

Переходы

Давайте к примеру выше добавим еще один объект со схожей формой.

function V8Snapshot() {
  this.obj1 = { a: 1, b: 2, c: 3, d: 4, e: 5, f: 6 };
  this.obj2 = { a: 1, b: 2, d: 3, c: 4, e: 5, f: 6 };
}

const v8Snapshot1 = new V8Snapshot();

На первый взгляд, форма второго объекта очень похожа, но свойства c и d имеют другой порядок следования.

В массивах дескрипторов эти свойства будут иметь разные индексы. Класс с адресом @101187 имеет двух наследников.

Для большей наглядности прогоним лог скрипта через V8 System Analyzer.

Здесь хорошо видно, что изначальная форма { a, b, c, d, e, f } имеет расширение в точке c. Однако интерпретатор не узнает об этом, пока не начнет инициализацию второго объекта. Чтобы составить новое дерево классов, движку пришлось бы найти в куче подходящий по форме класс, разбить его на части, сформировать новые классы и переназначить их всем созданным объектам. Чтобы избежать этого, разработчики V8 решили разбивать класс на набор минимальных форм сразу, еще при первой инициализации объекта, начиная с пустого класса.

{}
{ a }
{ a, b }
{ a, b, c }
{ a, b, c, d }
{ a, b, c, d, e }
{ a, b, c, d, e, f }

Создание нового скрытого класса с добавлением или изменением какого-либо свойства называется переходом (transition). В нашем случае, у первого объекта изначально будет 6 переходов (+a, +b, +c и т.д.).

Такой подход позволяет: а) легко найти подходящую стартовую форму для нового объекта, б) нет необходимости ничего перестраивать, достаточно создать новый класс с ссылкой на подходящую минимальную форму.

              {}
              { a }
              { a, b }

{ a, b, c }            { a, b, d }
{ a, b, c, d }         { a, b, d, c }
{ a, b, c, d, e }      { a, b, d, c, e }
{ a, b, c, d, e, f }   { a, b, d, c, e, f }

Внутренние и внешние свойства объекта

Рассмотрим следующий пример:

d8> const obj1 = { a: 1 };
d8> obj1.b = 2;
d8>
d8> %DebugPrint(obj1);
DebugPrint: 0x2387001c942d: [JS_OBJECT_TYPE]
 - map: 0x2387000dabb1 <Map[16](HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x2387000c4b11 <Object map = 0x2387000c414d>
 - elements: 0x2387000006cd <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties: 0x2387001cb521 <PropertyArray[3]>
 - All own properties (excluding elements): {
    0x238700002a21: [String] in ReadOnlySpace: #a: 1 (const data field 0), location: in-object
    0x238700002a31: [String] in ReadOnlySpace: #b: 2 (const data field 1), location: properties[0]
 }
0x2387000dabb1: [Map] in OldSpace
 - map: 0x2387000c3c29 <MetaMap (0x2387000c3c79 <NativeContext[285]>)>
 - type: JS_OBJECT_TYPE
 - instance size: 16
 - inobject properties: 1
 - unused property fields: 2
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - back pointer: 0x2387000d9ca1 <Map[16](HOLEY_ELEMENTS)>
 - prototype_validity cell: 0x2387000dabd9 <Cell value= 0>
 - instance descriptors (own) #2: 0x2387001cb4f9 <DescriptorArray[2]>
 - prototype: 0x2387000c4b11 <Object map = 0x2387000c414d>
 - constructor: 0x2387000c4655 <JSFunction Object (sfi = 0x238700335385)>
 - dependent code: 0x2387000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0
 
 {a: 1, b: 2}

Если внимательно посмотреть на набор значений этого объекта, мы увидим, что свойство a помечено как in-object, а свойство b - как элемент массива properties.

- All own properties (excluding elements): {
    ... #a: 1 (const data field 0), location: in-object
    ... #b: 2 (const data field 1), location: properties[0]
 }

Этот пример показывает, что часть свойств хранится непосредственно внутри самого объекта ("in-object"), а часть свойств - во внешнем хранилище свойств. Связано это с тем, что согласно спецификации ECMA-262, объекты JavaScript не имеют фиксированного размера. Добавляя или удаляя свойства в объекте, меняется его размер. Из-за этого возникает вопрос: какую область памяти выделить под объект? Более того, как расширить уже аллоцированную память объекта? Разработчики V8 решили эти вопросы следующим образом.

Внутренние свойства

В момент первичной инициализации литерал объекта уже распарсен, и AST-дерево содержит информацию о свойствах, указанных в момент инициализации. Набор таких свойств помещается непосредственно внутрь объекта, что позволяет обращаться к ним максимально быстро и с минимальными затратами. Эти свойства называются in-object.

Давайте еще раз взглянем на класс пустого объекта.

d8> const obj1 = {}
d8>
d8> %DebugPrint(obj1);
DebugPrint: 0x2d56001c9ed1: [JS_OBJECT_TYPE]
 - map: 0x2d56000c4945 <Map[28](HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x2d56000c4b11 <Object map = 0x2d56000c414d>
 - elements: 0x2d56000006cd <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties: 0x2d56000006cd <FixedArray[0]>
 - All own properties (excluding elements): {}
0x2d56000c4945: [Map] in OldSpace
 - map: 0x2d56000c3c29 <MetaMap (0x2d56000c3c79 <NativeContext[285]>)>
 - type: JS_OBJECT_TYPE
 - instance size: 28
 - inobject properties: 4
 - unused property fields: 4
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - back pointer: 0x2d5600000061 <undefined>
 - prototype_validity cell: 0x2d5600000a31 <Cell value= 1>
 - instance descriptors (own) #0: 0x2d5600000701 <DescriptorArray[0]>
 - prototype: 0x2d56000c4b11 <Object map = 0x2d56000c414d>
 - constructor: 0x2d56000c4655 <JSFunction Object (sfi = 0x2d5600335385)>
 - dependent code: 0x2d56000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

Хочу обратить внимание на параметр inobject properties. Здесь он равен 4, хотя в объекте еще нет ни одного свойства. Дело в том, что у пустых объектов, по умолчанию есть несколько слотов для in-object свойств. В V8 количество таких слотов равно 4.

d8> obj1.a = 1;
d8> obj1.b = 2;
d8> obj1.c = 3;
d8> obj1.d = 4;
d8> obj1.e = 5;
d8> obj1.f = 6;
d8>
d8> %DebugPrint(obj1);
DebugPrint: 0x2d56001c9ed1: [JS_OBJECT_TYPE]
 - map: 0x2d56000db291 <Map[28](HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x2d56000c4b11 <Object map = 0x2d56000c414d>
 - elements: 0x2d56000006cd <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties: 0x2d56001cc1a9 <PropertyArray[3]>
 - All own properties (excluding elements): {
    0x2d5600002a21: [String] in ReadOnlySpace: #a: 1 (const data field 0), location: in-object
    0x2d5600002a31: [String] in ReadOnlySpace: #b: 2 (const data field 1), location: in-object
    0x2d5600002a41: [String] in ReadOnlySpace: #c: 3 (const data field 2), location: in-object
    0x2d5600002a51: [String] in ReadOnlySpace: #d: 4 (const data field 3), location: in-object
    0x2d5600002a61: [String] in ReadOnlySpace: #e: 5 (const data field 4), location: properties[0]
    0x2d5600002a71: [String] in ReadOnlySpace: #f: 6 (const data field 5), location: properties[1]
 }
0x2d56000db291: [Map] in OldSpace
 - map: 0x2d56000c3c29 <MetaMap (0x2d56000c3c79 <NativeContext[285]>)>
 - type: JS_OBJECT_TYPE
 - instance size: 28
 - inobject properties: 4
 - unused property fields: 1
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - back pointer: 0x2d56000db169 <Map[28](HOLEY_ELEMENTS)>
 - prototype_validity cell: 0x2d56000dace9 <Cell value= 0>
 - instance descriptors (own) #6: 0x2d56001cc1f5 <DescriptorArray[6]>
 - prototype: 0x2d56000c4b11 <Object map = 0x2d56000c414d>
 - constructor: 0x2d56000c4655 <JSFunction Object (sfi = 0x2d5600335385)>
 - dependent code: 0x2d56000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

Это значит, что первые 4 свойства, добавленные в пустой объект будут размещены в эти слоты как in-object.

Внешние свойства

Свойства, которые были добавлены после инициализации, уже не могут быть размещены внутри объекта, так как память под объект уже выделена. Чтобы не тратить ресурсы на переаллоцирование всего объекта, движок помещает такие свойства во внешнее хранилище, в данном случае, во внешний массив свойств, ссылка на который уже имеется внутри объекта. Такие свойства называются внешними или нормальными (именно такой термин можно нередко встретить в материалах разработчиков V8). Доступ к таким свойствам чуть менее быстрый, так как требуется резолв ссылки на хранилище и получение свойства по индексу. Но это намного эффективнее, чем переаллоцирование всего объекта.

Быстрые и медленные свойства

Внешнее свойство из примера выше, как мы только что рассмотрели, хранится во внешнем массиве свойств, связанном непосредственно с нашим объектом. Формат данных в этом массиве идентичен формату внутренних свойств. Другими словами, там хранятся только значения свойств, а метаинформация о них размещена в массиве дескрипторов, где также содержится информация и о внутренних свойствах. По сути, внешние свойства отличаются от внутренних только местом их хранения. И те, и другие условно можно считать быстрыми свойствами. Однако напомню, что JavaScript - это живой и гибкий язык программирования. Разработчик имеет возможность добавлять, удалять и изменять свойства объекта по своему усмотрению. Активное изменение набора свойств может привести к существенным затратам процессорного времени. Для оптимизации этого процесса V8 поддерживает так называемые "медленные" свойства. Суть медленных свойств заключается в использовании другого типа внешнего хранилища. Вместо массива значений свойства размещаются в отдельном объекте-словаре вместе со всеми их атрибутами. Доступ как к значениям, так и к атрибутам таких свойств осуществляется по их названию, которое служит ключом словаря.

d8> delete obj1.a;
d8>
d8> %DebugPrint(obj1)
DebugPrint: 0x2387001c942d: [JS_OBJECT_TYPE]
 - map: 0x2387000d6071 <Map[12](HOLEY_ELEMENTS)> [DictionaryProperties]
 - prototype: 0x2387000c4b11 <Object map = 0x2387000c414d>
 - elements: 0x2387000006cd <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties: 0x2387001cc1d9 <NameDictionary[30]>
 - All own properties (excluding elements): {
   b: 2 (data, dict_index: 2, attrs: [WEC])
 }
0x2387000d6071: [Map] in OldSpace
 - map: 0x2387000c3c29 <MetaMap (0x2387000c3c79 <NativeContext[285]>)>
 - type: JS_OBJECT_TYPE
 - instance size: 12
 - inobject properties: 0
 - unused property fields: 0
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - dictionary_map
 - may_have_interesting_properties
 - back pointer: 0x238700000061 <undefined>
 - prototype_validity cell: 0x238700000a31 <Cell value= 1>
 - instance descriptors (own) #0: 0x238700000701 <DescriptorArray[0]>
 - prototype: 0x2387000c4b11 <Object map = 0x2387000c414d>
 - constructor: 0x2387000c4655 <JSFunction Object (sfi = 0x238700335385)>
 - dependent code: 0x2387000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

{b: 2}

Мы удалили свойство obj1.a. Несмотря на то, что свойство было внутренним, мы полностью изменили форму скрытого класса. Если быть точным, мы его сократили, что отличается от типичного расширения формы. Это означает, что дерево форм стало короче, следовательно, дескрипторы и массив значений также должны быть перестроены. Все эти операции требуют определенных временных ресурсов. Чтобы избежать этого, движок изменяет способ хранения свойств объекта на медленный с использованием объекта-словаря. В данном примере словарь (NameDictionary) расположен по адресу 0x2387001cc1d9.

d8> %DebugPrintPtr(0x2387001cc1d9)
DebugPrint: 0x2387001cc1d9: [NameDictionary]
 - FixedArray length: 30
 - elements: 1
 - deleted: 1
 - capacity: 8
 - elements: {
              7: b -> 2 (data, dict_index: 2, attrs: [WEC])
 }
0x238700000ba1: [Map] in ReadOnlySpace
 - map: 0x2387000004c5 <MetaMap (0x23870000007d <null>)>
 - type: NAME_DICTIONARY_TYPE
 - instance size: variable
 - elements kind: HOLEY_ELEMENTS
 - enum length: invalid
 - stable_map
 - back pointer: 0x238700000061 <undefined>
 - prototype_validity cell: 0
 - instance descriptors (own) #0: 0x238700000701 <DescriptorArray[0]>
 - prototype: 0x23870000007d <null>
 - constructor: 0x23870000007d <null>
 - dependent code: 0x2387000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

39062729441753

Массивы

Согласно разделу 23.1 Array Objects спецификации, массив - это объект, ключи которого являются целыми числами от 0 до 2**32 - 2. С одной стороны, кажется, что с точки зрения скрытых классов массив ничем не отличается от обычного объекта. Однако на практике массивы бывают довольно большими. Что если в массиве тысячи элементов? Неужели на каждый элемент будет создан отдельный скрытый класс? Давайте посмотрим, как на самом деле выглядит скрытый класс массива.

d8> arr = [];
d8> arr[0] = 1;
d8> arr[1] = 2;
d8>
d8> %DebugPrint(arr); 
DebugPrint: 0x24001c9421: [JSArray]
 - map: 0x0024000ce6b1 <Map[16](PACKED_SMI_ELEMENTS)> [FastProperties]
 - prototype: 0x0024000ce925 <JSArray[0]>
 - elements: 0x0024001cb125 <FixedArray[17]> [PACKED_SMI_ELEMENTS]
 - length: 2
 - properties: 0x0024000006cd <FixedArray[0]>
 - All own properties (excluding elements): {
    0x2400000d41: [String] in ReadOnlySpace: #length: 0x00240030f6f9 <AccessorInfo name= 0x002400000d41 <String[6]: #length>, data= 0x002400000061 <undefined>> (const accessor descriptor), location: descriptor
 }
 - elements: 0x0024001cb125 <FixedArray[17]> {
           0: 1
           1: 2
        2-16: 0x0024000006e9 <the_hole_value>
 }
0x24000ce6b1: [Map] in OldSpace
 - map: 0x0024000c3c29 <MetaMap (0x0024000c3c79 <NativeContext[285]>)>
 - type: JS_ARRAY_TYPE
 - instance size: 16
 - inobject properties: 0
 - unused property fields: 0
 - elements kind: PACKED_SMI_ELEMENTS
 - enum length: invalid
 - back pointer: 0x002400000061 <undefined>
 - prototype_validity cell: 0x002400000a31 <Cell value= 1>
 - instance descriptors #1: 0x0024000cef3d <DescriptorArray[1]>
 - transitions #1: 0x0024000cef59 <TransitionArray[4]>Transition array #1:
     0x002400000e05 <Symbol: (elements_transition_symbol)>: (transition to HOLEY_SMI_ELEMENTS) -> 0x0024000cef71 <Map[16](HOLEY_SMI_ELEMENTS)>

 - prototype: 0x0024000ce925 <JSArray[0]>
 - constructor: 0x0024000ce61d <JSFunction Array (sfi = 0x2400335da5)>
 - dependent code: 0x0024000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

[1, 2]

Как мы видим, у скрытого класса этого объекта ссылка back pointer пустая, что означает отсутствие родительского класса, хотя мы добавили два элемента. Дело в том, что скрытый класс любого массива всегда имеет единую форму JS_ARRAY_TYPE. Это особенный скрытый класс, у которого в дескрипторах есть лишь одно свойство - length. Элементы массива же располагаются внутри объекта в структуре FixedArray. В действительности скрытые классы массивов все же могут наследоваться, поскольку сами элементы могут иметь различные типы данных, а ключи, в зависимости от числа, могут храниться разными способами для оптимизации доступа к ним. В этой статье я не буду подробно рассматривать все возможные переходы внутри массивов, так как это тема для отдельной статьи. Однако стоит иметь в виду, что разнообразные нестандартные манипуляции с ключами массивов могут привести к созданию древа классов для всех или части элементов.

d8> const arr = [];
d8> arr[-1] = 1;
d8> arr[2**32 - 1] = 2;
d8>
d8> %DebugPrint(arr)
DebugPrint: 0xe0b001c98c9: [JSArray]
 - map: 0x0e0b000dacc1 <Map[16](PACKED_SMI_ELEMENTS)> [FastProperties]
 - prototype: 0x0e0b000ce925 <JSArray[0]>
 - elements: 0x0e0b000006cd <FixedArray[0]> [PACKED_SMI_ELEMENTS]
 - length: 0
 - properties: 0x0e0b001cb5f1 <PropertyArray[3]>
 - All own properties (excluding elements): {
    0xe0b00000d41: [String] in ReadOnlySpace: #length: 0x0e0b0030f6f9 <AccessorInfo name= 0x0e0b00000d41 <String[6]: #length>, data= 0x0e0b00000061 <undefined>> (const accessor descriptor), location: descriptor
    0xe0b000dab35: [String] in OldSpace: #-1: 1 (const data field 0), location: properties[0]
    0xe0b000daca9: [String] in OldSpace: #4294967295: 2 (const data field 1), location: properties[1]
 }
0xe0b000dacc1: [Map] in OldSpace
 - map: 0x0e0b000c3c29 <MetaMap (0x0e0b000c3c79 <NativeContext[285]>)>
 - type: JS_ARRAY_TYPE
 - instance size: 16
 - inobject properties: 0
 - unused property fields: 1
 - elements kind: PACKED_SMI_ELEMENTS
 - enum length: invalid
 - stable_map
 - back pointer: 0x0e0b000dab45 <Map[16](PACKED_SMI_ELEMENTS)>
 - prototype_validity cell: 0x0e0b000dab95 <Cell value= 0>
 - instance descriptors (own) #3: 0x0e0b001cb651 <DescriptorArray[3]>
 - prototype: 0x0e0b000ce925 <JSArray[0]>
 - constructor: 0x0e0b000ce61d <JSFunction Array (sfi = 0xe0b00335da5)>
 - dependent code: 0x0e0b000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

[]

В примере выше оба элемента -1 и 2**32 - 1 не входят в диапазон возможных индексов массива [0 .. 2**32 - 2] и были объявлены как обычные свойства объекта с соответствующими формами и порождением дерева скрытых классов.

Еще одна нештатная ситуация возможна в случае попытки изменить атрибуты индекса. Чтобы элементы хранились в быстром хранилище, все индексы должны иметь одинаковую конфигурацию. Попытка изменить атрибуты любого из индексов не приведет к созданию отдельного свойства, но приведет к изменению типа хранилища на медленное, в котором будут храниться не только значения, но и атрибуты каждого индекса. По сути, здесь применяется то же правило, что и в случае с медленными свойствами объекта.

d8> const arr = [1];
d8> Object.defineProperty(arr, '0', { value: 2, writable:  false });      
d8> arr.push(3);
d8>
d8> %DebugPrint(arr);
DebugPrint: 0x29ee001c9425: [JSArray]
 - map: 0x29ee000dad05 <Map[16](DICTIONARY_ELEMENTS)> [FastProperties]
 - prototype: 0x29ee000ce925 <JSArray[0]>
 - elements: 0x29ee001cb391 <NumberDictionary[16]> [DICTIONARY_ELEMENTS]
 - length: 2
 - properties: 0x29ee000006cd <FixedArray[0]>
 - All own properties (excluding elements): {
    0x29ee00000d41: [String] in ReadOnlySpace: #length: 0x29ee0030f6f9 <AccessorInfo name= 0x29ee00000d41 <String[6]: #length>, data= 0x29ee00000061 <undefined>> (const accessor descriptor), location: descriptor
 }
 - elements: 0x29ee001cb391 <NumberDictionary[16]> {
   - requires_slow_elements
   0: 2 (data, dict_index: 0, attrs: [_EC])
   1: 3 (data, dict_index: 0, attrs: [WEC])
 }
0x29ee000dad05: [Map] in OldSpace
 - map: 0x29ee000c3c29 <MetaMap (0x29ee000c3c79 <NativeContext[285]>)>
 - type: JS_ARRAY_TYPE
 - instance size: 16
 - inobject properties: 0
 - unused property fields: 0
 - elements kind: DICTIONARY_ELEMENTS
 - enum length: invalid
 - stable_map
 - back pointer: 0x29ee000cf071 <Map[16](HOLEY_ELEMENTS)>
 - prototype_validity cell: 0x29ee00000a31 <Cell value= 1>
 - instance descriptors (own) #1: 0x29ee000cef3d <DescriptorArray[1]>
 - prototype: 0x29ee000ce925 <JSArray[0]>
 - constructor: 0x29ee000ce61d <JSFunction Array (sfi = 0x29ee00335da5)>
 - dependent code: 0x29ee000006dd <Other heap object (WEAK_ARRAY_LIST_TYPE)>
 - construction counter: 0

[2, 3]

Итог

В этой статье мы познакомились ближе с методами хранения свойств объектов, понятиями скрытого класса, формами объекта, дескрипторов объекта, внутренними и внешними свойствами, а также быстрым и медленным способами их хранения. Давайте теперь коротко вспомним основные тезисы и выводы.

• Каждый объект в JavaScript имеет свой основной внутренний класс и скрытый класс, описывающий его форму.
• Скрытые классы наследуют друг друга и выстраивются в деревья классов. Форма объекта { a: 1 } будет родительской для формы объекта { a: 1, b: 2 }.
• Порядок свойств имеет значение. Объекты { a: 1, b: 2 } и { b: 2, a: 1 } будут иметь две разные формы.
• Класс-наследник хранит ссылку на класс-родитель и информацию о том, что было изменено (переход).
• В дереве классов каждого объекта количество уровней не менее количества свойств в объекте.
• Самыми быстрыми свойствами объекта будут те, которые объявлены при инициализации. В следующем примере доступ к свойству obj1.a будет быстрее, чем к obj2.a.

const obj1 = { a: undefined };
obj1.a = 1; // <- "a" - in-object свойство

const obj2 = {};
obj2.a = 1; // <- "a" - внешнее свойство

• Нетипичные изменения формы объекта, такие как удаление свойства, могут привести к изменению типа хранения свойств на медленный. В следующем примере obj1 изменит свой тип на NamedDictionary, и доступ к его свойствам будет значительно медленнее, чем к свойствам obj2.

const obj1 = { a: 1, b: 2 };
delete obj1.a; // изменяет тип хранения на NameDictionary 

const obj2 = { a: 1, b: 2 };
obj2.a = undefined; // не меняет тип хранения свойств

• Если в объекте есть внешние свойства, а внутренних меньше 4-х, такой объект можно немного оптимизировать, так как пустой объект, по умолчанию имеет несколько слотов для in-object свойств.

const obj1 = { a: 1 };
obj1.b = 2;
obj1.c = 3;
obj1.d = 4;
obj1.e = 5;
obj1.f = 6;

%DebugPrint(obj1);
...
- All own properties (excluding elements): {
    ...#a: 1 (const data field 0), location: in-object
    ...#b: 2 (const data field 1), location: properties[0]
    ...#c: 3 (const data field 2), location: properties[1]
    ...#d: 4 (const data field 3), location: properties[2]
    ...#e: 5 (const data field 4), location: properties[3]
    ...#f: 6 (const data field 5), location: properties[4]
 }

const obj2 = Object.fromEntries(Object.entries(obj1));

%DebugPrint(obj2);
...
 - All own properties (excluding elements): {
    ...#a: 1 (const data field 0), location: in-object
    ...#b: 2 (const data field 1), location: in-object
    ...#c: 3 (const data field 2), location: in-object
    ...#d: 4 (const data field 3), location: in-object
    ...#e: 5 (const data field 4), location: properties[0]
    ...#f: 6 (const data field 5), location: properties[1]
 }

• Массив является обычным классом, форма которого имеет вид { length: [W__] }. Элементы массива хранятся в специальных структурах, ссылки на которые размещены внутри объекта. Добавление и удаление элементов массива не приводят к увеличению дерева классов.

const arr = [];
arr[0] = 1; // новый элемент массива не увеличивает дерево классов

const obj = {};
obj1[0] = 1; // каждое новое свойство объекта увеличивает дерево классов

• Использование нетипичных ключей в массиве, например не числовых или вне диапазона [0 .. 2**32 - 2]), приводит к созданию новых форм в дереве классов.

const arr = [];
arr[-1] = 1;
arr[2**32 - 1] = 2;
// Приведет к образованию дерева форм
// { length } => { length, [-1] } => { length, [-1], [2**32 - 1] }

• Попытка изменить атрибут элемента массива приведет к смене типа хранилища на медленный.

const arr = [1, 2, 3];
// { elements: {
//   #0: 1,
//   #1: 2,
//   #2: 3
// }}

Object.defineProperty(arr, '0', { writable: false };
// { elements: {
//   #0: { value: 1, attrs: [_EC] }, 
//   #1: { value: 2, attrs: [WEC] },
//   #2: { value: 3, attrs: [WEC] }
// }}

Мои телеграмм-каналы:

English version: https://blog.frontend-almanac.com/js-object-structure

Prop-drilling

Типичный подход выглядел примерно следующим образом.

class App extends React.Component {
  constructor(props) {
    super(props);

    // инциализация стейта значениями по умолчанию
    this.state = {
      a: '',
      b: 0,
    };
  }

  render() {
    // проброс данных из стейта в дочерний компонент
    return <Child a={this.state.a} b={this.state.b} />;
  }
}

class Child extends React.Component<any, any> {
  // дочерний компонент получает данные через ссылку this.props
  render() {
    return (
      <div>
        <div>{this.props.a}</div>
        <div>{this.props.b}</div>
      </div>
    );
  }
}

ReactDOM.render(<App />, document.getElementById('root'));

В примере выше данные хранятся в стейте верхнего компонента и передаются в дочерний компонент через свойства. Дочерний компонент также может иметь свой внутренний стейт.

class Child extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      c: 2,
    };
  }

  render() {
    return (
      <div>
        <div>{this.props.a}</div>
        <div>{this.props.b}</div>
        <Child2 c={this.state.c} />
      </div>
    );
  }
}

class Child2 extends React.Component {
  render() {
    return (
      <div>
        <div>{this.props.c}</div>
      </div>
    );
  }
}

Изменение состояния компонента в таком случае возможно только посредством вызова метода this.setState внутри компонента, то есть, дочерний компонент может обновить верхнеуровневые данные только при наличии соответствующего метода, переданного ему через те же свойства.

class App extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      a: '',
      b: 0,
    };
  }

  render() {
    return (
      <Child
        a={this.state.a}
        b={this.state.b}
        setB={(b) => {
          this.setState({ b });
        }}
      />
    );
  }
}

class Child extends React.Component<any, any> {
  constructor(props) {
    super(props);

    this.state = {
      c: 2,
    };
  }

  render() {
    return (
      <div>
        <div>{this.props.a}</div>
        <div>{this.props.b}</div>
        <Child2
          b={this.state.b}
          c={this.state.c}
          setB={this.props.setB}
        />
      </div>
    );
  }
}

class Child2 extends React.Component {
  render() {
    return (
      <div>
        <div>{this.props.c}</div>

        <button
          onClick={() => {
            this.props.setB(this.props.b + 1);
          }}
        >
          Increment
        </button>
      </div>
    );
  }
}

Уже на этом этапе проблема данного подхода становится очевидной. В реальных приложениях с большим набором компонентов эта схема приводит к так называемому prop-drilling, то есть массовому пробросу ссылок вниз по дереву компонентов и обратно наверх. Это неизбежно приводит:

а) к гонке обновления данных, то есть ситуация, когда два компонента, не зная друг о друге, пытаются обновить одну и ту же ссылку в стейте;

б) к тому, что компоненты должны выполнять транзитную роль для данных, которыми, фактически, не оперируют;

в) к сложности замены компонента в середине цепочки;

г) к длинному и запутанному графу ссылок на состояние.

Дополнительно, задачу осложняло еще и то, что простые функциональные компоненты в первых версиях React не имели внутреннего стейта (хуков тогда еще не было).

const Child3 = ({ c }) => {
  // У функционального компонента нет this.state
  // хук useState() появился только в 2019-м году с версии 16.8.0
  return <div>{c}</div>;
};

Flux

Надо ли говорить, что показанный выше подход вел к большому количеству ошибок и экспоненциально нарастающей сложности кода? Не могли избежать этого и сами создатели React. В былые годы на сайте "Facebook" то и дело появлялись ошибки, связанные с различными асинхронными процессами, такими как исчезающие или не отображающиеся уведомления и другие. В связи с этим разработчики принялись за проработку нового подхода к организации управления состоянием данных в приложении. Так появился паттерн Flux. Прародителем этого паттерна стал классический и очень популярный в те времена паттерн MVC. Суть Flux заключается в том, что данные всегда должны двигаться в одном направлении и храниться в отдельном крупном хранилище. Обновление данных осуществляется с помощью специальных методов-экшенов, не привязанных к какому-либо конкретному компоненту.

На основе паттерна Flux появилось много библиотек для управления состоянием. Такие как Fluxxor, Flummox, Baobab и еще много других. Самой популярной из них, на протяжении многих лет и по сей день, является Redux.

Redux

Библиотека управления состоянием приложения Redux появилась в 2015 году и с тех пор приобрела огромную популярность. Redux доказал эффективность подхода Flux и до недавнего времени фактически являлся стандартом в мире React.

Архитектура типичного приложения обрела следующий вид.

import { connect, Provider } from 'react-redux';

const defaultState1 = {
  a: "",
  b: 0
};

const reducer1 = function(state = defaultState1, action) {
  switch(action.type){
    case "A_TYPE":
      return { ...state, a: action.payload };
    case "B_TYPE":
      return { ...state, b: action.payload };
  }

  return state;
};

const defaultState2 = {
  c: false,
  d: []
};

const reducer2 = function(state = defaultState2, action) {
  switch(action.type){
    case "C_TYPE":
      return { ...state, c: action.payload };
    case "D_TYPE":
      return { ...state, c: action.payload };
  }

  return state;
};

const store = createStore(
  combineReducers({
    reducer1,
    reducer2
  })
);

const App = connect(
  (state) => ({ b: state.reducer1.b }),
  (dispatch) => {
    setB: (value) => dispatch({ type: "B_TYPE", payload: value }) 
  }
)(({ b }) => {
  return (
    <Provider store={store}>
      <button
        onClick={() => {
          setB(b + 1)
        }}
      >
        Increase {b}
      </button>
    </Provider>
  );
});

Теперь все данные в приложении хранятся в отдельном большом дереве за пределами какого-либо компонента. К дереву можно «подключиться», т.е. слушать все изменения нужной ветки и реагировать на эти изменения. Обновить значение в дереве можно, послав так называемый экшен - событие, содержащее объект с полем type. По этому type редьюсер поймет, что это за экшен и выполнит соответствующую мутацию дерева.

В целом, вопрос, казалось бы, решен. Данные живут отдельно, компоненты отдельно. Никаких гонок и проп-дриллинга. Цена этому, правда, громоздкие конструкции по обеспечению жизнедеятельности самого хранилища. На каждое свойство дерева нужен редьюсер и экшен. А компонент необходимо подписывать на изменение всего дерева, чтобы получить данные. Кроме того, в более сложных приложениях, по мере роста дерева, начинают возникать специфические кейсы. Например, в глубоко вложенных объектах становится сложнее следить за иммутабельностью, что приводит к несрабатывающим реакциям на изменения стейта. На помощь пришли дополнительные библиотеки, такие как immutable-js и reselect.

Потом встал вопрос работы с запросами, ведь именно запросы в большинстве случаев являются источником данных в приложении. А значит, появилась необходимость добавить асинхронность в редюсеры. Так появились redux-thunk и redux-saga. Однако и этого было недостаточно.

Запросы, помимо данных, имеют еще и свое собственное состояние. Среднестатистическому приложению, как минимум, требуется знать, находится ли запрос еще в процессе или ответ уже получен. Традиционно, флаг выполнения запроса (обычно его называют "isFetching" или "isLoading") лежал тут же в дереве, что требовало на каждый запрос держать один и тот же механизм выставления этого флага. Вместе с флагом загрузки в такой же ситуации находилась и обработка ошибок запроса. Текст ошибки также хранился в дереве рядом с данными и флагом загрузки. Если копнуть еще глубже, продвинутые приложения в целях оптимизации захотели кэшировать ответы на запросы, чтобы не перезапрашивать данные по сети каждый раз, когда, к примеру, монтируется компонент. Все эти рутиные операции и оптимизации еще больше раздували и без того не маленький код, обслуживающий стейт-дерево. Поэтому появление таких библиотек, как, например, redux-toolkit (RTK) выглядит вполне логично. Библиотека RTK позволяет организовать работу со стейт-деревом в одном общем паттерне. А в сочетании с дополнительным rtk-query можно получить кэширование запросов и информацию об их состоянии из коробки. Правда, от экшенов и редюсеров избавиться таким образом все равно не получится.

useReducer

Redux и прочие Flux-подобные библиотеки являются сторонними разработками. Конечно же, команда React не осталась в стороне и добавила в API возможность работать в стиле Flux. Фактически, это выразилось в появлении хука useReducer в версии React 16.8.0.

Тот же пример, что был приведен выше, теперь можно оформить следующим образом без подключения Redux.

const reducer = (state, action) => {
  switch (action.type) {
    case 'A_TYPE':
      return { ...state, a: action.payload };
    case 'B_TYPE':
      return { ...state, b: action.payload };

    default:
      return state;
  }
};

export const App = () => {
  const [state, dispatch] = useReducer(reducer, { a: "", b: 0 });

  return (
    <button
      onClick={() => {
        dispatch({ type: "A_TYPE", payload: b + 1 })
      }}
    >
      Increase {state.b}
    </button>
  );
};

Однако все перечисленные ранее вопросы, связанные с работой Redux, справедливы и для useReducer. А поскольку Redux оброс массой дополнительных библиотек и инструментов, хук не получил большой популярности среди разработчиков.

React контекст

Контекст в React существовал с самых первых версий. Однако официально он был включен в API только начиная с версии 16.3.0 в 2018 году. Суть подхода заключается в следующем: данные, которые требуется сделать доступными для нескольких компонентов, помещаются в отдельное независимое место посредством метода API createContext().

const MyContext = createContext({ a: "", b: 0 });

Результатом метода createContext является объект, содержащий ссылки на провайдер и консьюмер созданного контекста.

Провайдер должен оборачивать компонент или дерево компонентов, которые будут иметь доступ к данным внутри этого контекста.

class App extends React.Component<any, any> {
  render() {
    return (
      <MyContext.Provider value={{ a: '', b: 0 }}>
        <Child />
      </MyContext.Provider>
    );
  }
}

class Child extends React.Component<any, any> {
  contextType = MyContext;

  render() {
    return (
      <div>
        <div>{this.context.a}</div>
        <Child2 />
      </div>
    );
  }
}

const Child2 = () => {
  return (
    <MyContext.Consumer>
      {(context) => <div>{context.b}</div>}
    </MyContext.Consumer>
  );
};

Доступ к контексту осуществляется через ссылку-консьюмер. В классовом компоненте имеется возможность привязать контекст к компоненту, определив свойство contextType. В функциональных компонентах можно воспользоваться прямой ссылкой на консьюмер MyContext.Consumer.

С появлением официальной поддержки API контекста для функциональных компонентов стал доступен хук useContext.

const Child2 = () => {
  const { b } = useContext(MyContext);

  return (
    <div>{b}</div>
  );
};

За обновлением данных в контексте отвечает компонент, создавший его.

class App extends React.Component<any, any> {
  const [a, setA] = useState("");
  const [b, setB] = useState(0);

  render() {
    return (
      <MyContext.Provider value={{ a, b }}>
        <Child />
        <button onClick={() => setB(b => b + 1)}>
          Increase {b}
        </button>
      </MyContext.Provider>
    );
  }
}

Если требуется делегировать возможность обновления данных нижестоящим компонентам, ссылку на экшен можно положить туда же, в сам контекст.

class App extends React.Component<any, any> {
  const [a, setA] = useState("");
  const [b, setB] = useState(0);

  render() {
    return (
      <MyContext.Provider value={{ a, b, setB }}>
        <Child />
      </MyContext.Provider>
    );
  }
}

const Child = () => {
  const { b, setB } = useContext(MyContext);

  return (
    <button onClick={() => setB(b => b + 1)}>
      Increase {b}
    </button>
  );
};

Так можно контролировать процесс мутации контекста и давать возможность изменять только те его части, которые нужно. Более того, можно добавить промежуточные действия, подобные "Redux middleware", и иметь еще больший контроль над мутациями.

class App extends React.Component<any, any> {
  const [a, setA] = useState("");
  const [b, setB] = useState(0);
  
  const increaseB = () => {
    setB((b) => {
      return b < 10 ? b + 1 : b;
    });
  };

  render() {
    return (
      <MyContext.Provider value={{ a, b, increaseB }}>
        <Child />
      </MyContext.Provider>
    );
  }
}

const Child = () => {
  const { b, increaseB } = useContext(MyContext);

  return (
    <button onClick={increaseB}>
      Increase {b}
    </button>
  );
};

К преимуществам контекста можно отнести

Гибкость

Хранилище контекста максимально примитивно, а API состоит из простых методов-обёрток. Следовательно, разработчик имеет максимальный контроль на всех этапах проектирования контекста.

Селективность

В отличие от Redux с его глобальным деревом, каждый конкретный контекст имеет возможность обернуть только нужные компоненты. И наоборот, компонент может быть обернут сразу в несколько контекстов. Это позволяет контролировать, какие данные и где будут доступны.

Уникальность

В ряде случаев может возникнуть необходимость продублировать модель контекста. Такое может понадобиться, например, при работе с массивами.

import { connect, Provider } from 'react-redux';

const defaultState = {
  items: [
    { id: 1, name: "item 1" },
    { id: 2, name: "item 2" },
    { id: 3, name: "item 3" },
  ],
  selectedId: undefined,
};

const reducer = function(state = defaultState, action) {
  switch(action.type){
    case "SET_SELECTED_ID_TYPE":
      return {
        ...state,
        selectedId: action.id,
      };
    default:
      return state;
  }

  return state;
};

const store = createStore(reducer);

const SelectedItem = connect(
  (state) => ({ item: state.reducer.items.find(item => item.id === state.selectedId) }),
)(({ item }) => {
  return item ? null : (
    <div>
      Seleceted item: {item?.title}
    </div>
  );
});

const ItemsList = connect(
  (state) => ({
    items: state.reducer.items,
  }),
  (dispatch = {
    setItem: (id) => dispatch({ type: 'SET_SELECTED_ID_TYPE', id }),
  })
)(({ items, setItem }) => {
  return (
    <div>
      {items.map((item) => (
        <button key={item.id} onClick={() => setItem(item.id)}>
          {item.title}
        </button>
      ))}

      <SelectedItem />
    </div>
  );
});

В данном примере все, кажется, хорошо, пока компонент ItemsList смонтирован. Однако, если мы его размонтируем, например, изменим маршрут, а затем вернемся к нему снова, в дереве Redux останется старое значение selectedId. В случае, если мы ожидаем увидеть здесь значение по умолчанию, а не старое, придется заботиться об этом отдельно и дописывать соответствующую логику.

Данный пример довольно простой. На практике встречаются гораздо более сложные случаи, в которых уже не обойтись простым ресет-экшеном.

В случае с контекстом архитектура могла бы выглядеть, например, так.

const ItemContext = createContext();

const SelectedItem: FC = ({ title }) => {
  const { title } = useContext(ItemContext);

  return <div>Selected item: {title}</div>;
};

const ItemsList: FC = () => {
  const [items] = useState([
    { id: 1, name: 'item 1' },
    { id: 2, name: 'item 2' },
    { id: 3, name: 'item 3' },
  ]);

  const [selectedItemId, setSelectedItemId] = useState();

  const item = useMemo(
    () => items.find((item) => item.id === selectedItemId),
    [items, selectedItemId]
  );

  return (
    <div>
      {items.map((item) => (
        <button key={item.id} onClick={() => setSelectedItemId(item.id)}>
          {item.title}
        </button>
      ))}

      {item && (
        <ItemContext.Provider value={item}>
          <SelectedItem />
        </ItemContext.Provider>
      )}
    </div>
  );
};

Поскольку данные живут внутри компонента ItemsList, при его перемонтировании стейт всегда будет иметь исходный вид, и нам не надо дополнительно беспокоиться о его сбросе.

В то же время, компонент SelectedItem оперирует контекстом ItemContext и вообще не знает, откуда и как в него попали данные.

Универсальный паттерн применения React контекста

Ниже я представлю универсальный шаблон типичного использования контекста в реальном приложении. Как и Redux, контексты хорошо дружат с TypeScript, поэтому сразу приведу пример с типизацией.

Для начала создадим независимый контекст и отдельный компонент-провайдер для него.

// MyContext.tsx
import React, {
  createContext,
  Dispatch,
  FC,
  PropsWithChildren,
  SetStateAction,
  useCallback,
  useContext,
  useMemo,
  useState,
} from 'react';

export interface MyContextProps {
  myVar: string;
  setMyVar: Dispatch<SetStateAction<MyContextProps['myVar']>>;

  someAction: (a: number, b?: boolean) => void;
}

export const MyContext = createContext<MyContextProps>({
  myVar: '',
  setMyVar: () => {},

  someAction: () => {},
});

// Вместо WithMyContext можно использовать более традиционное
// название MyContextProvder
export const WithMyContext: FC<PropsWithChildren> = ({ children }) => {
  const [myVar, setMyVar] = useState<MyContextProps['myVar']>('');

  const someAction = useCallback<MyContextProps['someAction']>(
    (a, b) => {},
    []
  );

  const value = useMemo<MyContextProps>(
    () => ({
      myVar,
      setMyVar,

      someAction,
    }),
    [myVar, someAction]
  );

  return <MyContext.Provider value={value}>{children}</MyContext.Provider>;
};

// Создадим, также отдельный хук для удобства
export const useMyContext = () => {
  return useContext(MyContext);
};

Контекст готов, осталось обернуть в него нужный компонент.

<WithMyContext>
  <MyComponent />
</WithMyContext>

Или, например, конкретный роут "react-router"

<Route element={(
  <WithMyContext>
    <Outlet />
  </WithMyContext>
)}>
  <Route …>
</Route>

Теперь контекст доступен для использования внутри вложенных компонентов.

import { FC } from 'react';

import { useMyContext } from ‘./MyContext';

export const MyComponent: FC = () => {
  const { myVar } = useMyContext();

  return <div>My component {myVar}</div>;
};

Мои телеграмм-каналы:

English version: https://blog.frontend-almanac.com/react-state-management

Что собирается сборщиком мусора

Прежде чем погрузиться в процесс самой сборки мусора, давайте сначала разберемся, что именно V8 собирает и как трассирует объекты.

Во время работы V8 в памяти может находиться множество разных структур данных. Часть этих структур является внутренними представлениями самого V8, такими как скрытые классы (hidden classes), списки, очереди и многое другое. Другая часть - это объекты JavaScript. Практически все типы данных внутри V8, по факту являются объектами, за исключением так называемых SMI - маленьких чисел не более 2^30 - 1, они хранятся в памяти прямым бинарным значением, а все переменные, имеющее такое значение, хранят ссылку на область памяти с этим конкретным SMI-значением. Подробнее про это я писал в статье Глубокий JS. В память о типах и данных. Все остальные типы представлены в памяти в виде объектов и имитируют свою мутабельность/иммутабельность в соответствии со спецификацией ECMA-262, выдавая, как мы привыкли говорить, "примитивные" или "ссылочные" типы.

Вообще, процесс сборки мусора не ограничивается объектами JavaScript. Движок Chromium предусматривает сборку всего, что может вообще быть собрано, будь то удаленные элементы HTML, не используемые таблицы стилей CSS и ресурсы, завершенная анимация и многое другое. Так как Chromium написан на языке C++, его внутренние объекты движка являются, очевидно, классами C++. Однако, объекты JavaScript, хоть и созданы средствами того же языка, являются более абстрактными понятиями и должны реализовывать требования спецификации ECMA-262. В частности, объекты JavaScript не имеют фиксированного размера и могу меняться динамически. А куча JavaScript, по своей структуре отличается от кучи C++. Как такие объекты размещаются в памяти посмотрим чуть ниже. Сейчас важно понять, что процесс сборки мертвых объектов JavaScript будет несколько расходиться со сборкой объектов C++.

Несколько лет назад, приблизительно в 2018-м году команда Chromium начала создавать систему сборки мертвых объектов C++. Система получила название Oilpan и стала частью внутреннего движка рендеринга Blink. Позже, в 2020-м, разработчики решили перенести систему внутрь движка V8, так как, с одной стороны, V8 использует те же механизмы сборки мусора, что и Blink, с другой, перенос в V8 делает систему доступной для сторонних разработчиков, которые интегрируют движок V8, но не используют Blink, например, Node.js. В результате, в API V8 появилась директория cppgc.

Трассировка объектов

Как я уже говорил, суть сборки мусора заключается в освобождении памяти от "мертвых" объектов. Мертвым считается объект, на который нет больше ни одной ссылки, а значит, к нему невозможно получить доступ. Следовательно, такой объект больше не может быть использован и его следует очистить. И наоборот, "живой" объект - это объект, до которого можно добраться по ссылкам от корня.

На рисунке выше изображена упрощенная схема трассировки. Ссылки на все созданные объекты хранятся в отдельной глобальной таблице GlobalGCInfoTable. Во время работы сборщика мусора, происходит итеративный проход объектов от корня (корней может быть несколько, проход осуществляется по всем активным корням). Объекты, до которых смог дотянуться сборщик мусора, будут считаться живыми, они обозначены черным цветом. Все остальные объекты являются "мертвыми" (обозначены белым цветом).

Трассировка объектов C++

Чуть выше я говорил, то объекты C++ отличаются от объектов JavaScript. Дело в том, что объекты JavaScript стандартизированы и описаны в разделе 6.1.7 The Object Type спецификации. Что делает их предсказуемыми для сборщика мусора. Объекты же C++ не стандартизированы и их структуры могут сильно отличаться. Более того, не каждый объект C++ должен быть потенциально очищаемый. В связи с этим, для объектов C++ в Oilpan был предусмотрен специальный API.

В блоге движка V8 этому был посвящен отдельный пост High-performance garbage collection for C++. Не буду пересказывать весь пост, обозначу только основную концепцию. Объекты C++, которые хотят быть очищаемыми сборщиком мусоры, должны реализовывать интерфейсы GarbageCollected или GarbageCollectedMixin. Фактически, это означает, что объект должен иметь метод Trace(), в котором, сам же этот объект должен вызвать трассировку других объектов, на которые ссылается.

Например, вот так выглядит трассировка класса RunningAnimation (на момент написания статьи, версия Chromium 124.0.6339.1):

src/third_party/blink/renderer/core/animation/css/css_animations.h

class RunningAnimation final : public GarbageCollected<RunningAnimation> {
 public:
  RunningAnimation(Animation* animation, NewCSSAnimation new_animation)
      : animation(animation),
        name(new_animation.name),
        name_index(new_animation.name_index),
        specified_timing(new_animation.timing),
        style_rule(new_animation.style_rule),
        style_rule_version(new_animation.style_rule_version),
        play_state_list(new_animation.play_state_list) {}

  AnimationTimeline* Timeline() const {
    return animation->TimelineInternal();
  }
  const std::optional<TimelineOffset>& RangeStart() const {
    return animation->GetRangeStartInternal();
  }
  const std::optional<TimelineOffset>& RangeEnd() const {
    return animation->GetRangeEndInternal();
  }

  void Update(UpdatedCSSAnimation update) {
    DCHECK_EQ(update.animation, animation);
    style_rule = update.style_rule;
    style_rule_version = update.style_rule_version;
    play_state_list = update.play_state_list;
    specified_timing = update.specified_timing;
  }

  void Trace(Visitor* visitor) const {
    visitor->Trace(animation);
    visitor->Trace(style_rule);
  }

  Member<Animation> animation;
  AtomicString name;
  size_t name_index;
  Timing specified_timing;
  Member<StyleRuleKeyframes> style_rule;
  unsigned style_rule_version;
  Vector<EAnimPlayState> play_state_list;
};

Здесь мы видим, что класс реализует интерфейс GarbageCollected, а его метод Trace запускает трассировку внутренних объектов animation и style_rule.

Трассировка объектов JavaScript.

В отличие от объектов C++ и системы Oilpan, про объекты JavaScript официальных публикаций нет. Поэтому, не редко, трассировку объектов JavaScript ошибочно ставят в один ряд с объектами C++. На самом же деле, объекты JavaScript полностью контролируются движком V8 и живут в специальной куче V8. А значит, нет никакой необходимости в реализации дополнительного, управляемого из вне, API. Каждый объект JavaScript является наследником класса HeadObject, который имеет Iterate, IterateFast, IterateBody и IterateBodyFast. А сама куча имеет метод Visit, который запускает трассировку по объектам в этой куче (на момент написания статьи, версия V8 12.4.147)

src/objects/heap-object.h#204

// HeapObject is the superclass for all classes describing heap allocated
// objects.
class HeapObject : public TaggedImpl<HeapObjectReferenceType::STRONG, Address> {
 public:
  
  ...
  
  // Iterates over pointers contained in the object (including the Map).
  // If it's not performance critical iteration use the non-templatized
  // version.
  void Iterate(PtrComprCageBase cage_base, ObjectVisitor* v);

  template <typename ObjectVisitor>
  inline void IterateFast(PtrComprCageBase cage_base, ObjectVisitor* v);

  template <typename ObjectVisitor>
  inline void IterateFast(Tagged<Map> map, ObjectVisitor* v);

  template <typename ObjectVisitor>
  inline void IterateFast(Tagged<Map> map, int object_size, ObjectVisitor* v);

  // Iterates over all pointers contained in the object except the
  // first map pointer.  The object type is given in the first
  // parameter. This function does not access the map pointer in the
  // object, and so is safe to call while the map pointer is modified.
  // If it's not performance critical iteration use the non-templatized
  // version.
  void IterateBody(PtrComprCageBase cage_base, ObjectVisitor* v);
  void IterateBody(Tagged<Map> map, int object_size, ObjectVisitor* v);

  template <typename ObjectVisitor>
  inline void IterateBodyFast(PtrComprCageBase cage_base, ObjectVisitor* v);

  template <typename ObjectVisitor>
  inline void IterateBodyFast(Tagged<Map> map, int object_size,
                            ObjectVisitor* v);
  
  ...
} 

Поколения сборки мусора

Процедура нахождения мертвых объектов и их очистка, сама по себе, может быть весьма небыстрой. В современных приложениях в памяти могут находиться тысячи объектов, а их размер может превышать 1 Gb. Если речь идет о сборке объектов C++, работу можно переложить в отдельные потоки и запускать по требованию. Однако, если мы говорим о JavaScript, будучи однопоточным и не имеющим механизма синхронизации между потоками, при выполнении полной трассировки объектов на регулярной основе, разного рода задержки и снижение производительности, практически гарантированы. С этого момента и далее будем говорить о реализации сборки мусора именно JavaScript-объектов.

Чтобы не нагружать систему и проводить процесс сборки мусора незаметно для пользователя, команда V8 решила разбить процесс на части и работать над каждой из них отдельно.

Существует гипотеза, под названием infant mortality или generational hypothesis, согласно которой, в большинстве случаев, молодые объекты умрут раньше с большей вероятности, чем старые.

Так, в V8 появилось понятие "поколение" (generation). Существуют "молодое поколение" (young generation) и "старое поколение" (old generation).

Куча, условно разбивается на маленькие young generations (до 16 Mb), куда попадают все только что аллоцированные объекты. Old generation предназначена для старых объектов и может быть размером до 1.4 Gb.

Дополнительно, оба поколения организованы в, так называемые страницы (pages) по 1 Mb. Объекты больше 600 Кb размещаются в отдельных страницах и считаются частью old generation.

Old generation, так же, включает в себя code space со всеми исполняемыми объектами кода и map space с вовлеченными скрытыми классами (hidden classes).

Полупространственное размещение объектов в young generation

Чтобы двинуться дальше и начать разбираться в удалении объектов из памяти, давай, для начала поймем, как эти объекты в памяти хранятся.

Я уже упоминал, что JavaScript работает в одном потоке. Он не требует синхронизации, а каждый JavaScript-контекст получает свою персональную кучу. Весь последующий алгоритм будет строиться исходя из этих фактов и необходимости уместить все процессы в одном потоке.

Итак, young generation делится на два полупространства (semi-space), активное и неактивное. Все новые объекты изначально размещаются в текущем активном полупространстве используя метод bump-pointer.

Метод заключается в том, что в куче всегда есть указатель на текущую свободную область. При создании нового объекта, этот указатель будет являться началом объекта. Конец объекта определяется простым подсчетом его размера. Определив размер и, соответственно конец объекты, указатель смещается на следующий свободный адрес.

Как только полупространство полностью заполнилось, в работу вступает механизм Scavanger. Его задача - пройтись по живым объектам и переместить их в новое, неактивное полупространство. Эта операция называется Minor Garbage Collection (второстепенная сборка мусора).

После этого два полупространства меняются местами. Текущее активное полупространство становится неактивным, а неактивное очищается и становится активным. Таким образом, уже со второй итерации в неактивном полупространстве могу оставаться ссылки на живые объекты. При следующем выполнении Minor Garbage Collection, если объекты уже были один раз помещены во второе полупространство - они считаются старыми и перемещаются в old generation, а мертвые - удаляются.

Продолжительность Minor Garbage Collection зависит от количества живых объектов в young generation. Если все объекты являются мертвыми, процесс займет меньше 1 ms. Однако, если все или большинство объектов живые - значительно дольше.

Old generation

Old generation тоже использует метод bump-pointer для размещения объектов, а указатели хранятся в отдельных сводных таблицах, по аналогии с той, что я приводил в начале статьи.

Это поколение очищается другим процессом, под названием Major Garbage Collection (основная сборка мусора). Запускается он, когда размер живых объектов в old generation превышает эвристически рассчитанный предел.

Для уменьшения задержки и потребления памяти, old generation использует метод mark-sweep-comparator. Задержка во время маркировки зависит от количества живых объектов, которые должны быть промаркированы. Маркировка всей кучи может занимать до 100 ms для больших Web-страниц. Чтобы избежать этого, V8 маркирует объекты маленькими порциями, такими, чтобы каждый шаг не превышал 5 ms.

Сама схема называется "трехцветная маркировка" (tricolor marking scheme). Более подробно про процесс маркировку можно почитать в после Concurrent marking in V8 блога V8. Опять же, пересказывать пост полностью смысла не имеет. Обозначу общая суть процесса. Каждый объект находится в одном из трех статусов, условно обозначенных цветами. На самом деле, статус объекта - это 2-х битное поле, где

• 00 - белый - исходный статус всех новых объектов. Он означает, что объект еще не был обнаружен сборщиком.
• 01 - серый - в этот статус объект переходит сразу, как только сборщик до него добрался. Такой объект встает в список на дальнейшую трассировку.
• 11 - черный - конечный статус, означает, что сборщик посетил все дочерние узлы объекта и его можно убрать из списка трассировки.

Такая схема позволяет ставить задачи по маркировке в очередь, частями, не блокирую, надолго, главный поток. Процесс будет завершен, когда список объект на трассировку опустеет.

Однако, здесь имеется одна проблема. Между шагами маркировки выполняется JavaScript код, который может добавить новые объекты или удалить старые. Что делает статус уже промаркированных объектов неактуальным. Чтобы решить эту проблему, движок должен сообщать сборщику обо всех изменения в дереве объектов. Делается это посредством, так называемого write-barrier. В блоге V8 приводится пример реализации такого барьера.

// Called after `object.field = value`.
write_barrier(object, field_offset, value) {
  if (color(object) == black && color(value) == white) {
    set_color(value, grey);
    marking_worklist.push(value);
  }
}

Каждый раз при добавлении нового объекта в уже существующий срабатывает функция-барьер, которая проверят, был ли родитель уже промаркирован и, в случае, если дочерний объект еще ни к чему не привязан, родительский будет возвращен в список на трассировку, а сам этот объект сразу перейдет в статус серых.

Данный код, конечно же, сейчас уже не актуален. На сегодняшний день барьеры гораздо сложнее и выглядят несколько иначе, но суть осталась прежней. Есть разные варианты реализации для разных случаев. Для полноты картины приведу часть кода реального барьера V8.

src/heap/marking-barrier-inl.h#64

void MarkingBarrier::MarkValueShared(Tagged<HeapObject> value) {
  // Value is either in read-only space or shared heap.
  DCHECK(InAnySharedSpace(value));
  // We should only reach this on client isolates (= worker isolates).
  DCHECK(!is_shared_space_isolate_);
  DCHECK(shared_heap_worklist_.has_value());
  // Mark shared object and push it onto shared heap worklist.
  if (marking_state_.TryMark(value)) {
    shared_heap_worklist_->Push(value);
  }
}

void MarkingBarrier::MarkValueLocal(Tagged<HeapObject> value) {
  DCHECK(!InReadOnlySpace(value));
  if (is_minor()) {
    // We do not need to insert into RememberedSet<OLD_TO_NEW> here because the
    // C++ marking barrier already does this for us.
    // TODO(v8:13012): Consider updating C++ barriers to respect
    // POINTERS_TO_HERE_ARE_INTERESTING and POINTERS_FROM_HERE_ARE_INTERESTING
    // page flags and make the following branch a DCHECK.
    if (Heap::InYoungGeneration(value)) {
      WhiteToGreyAndPush(value);  // NEW->NEW
    }
  } else {
    if (WhiteToGreyAndPush(value)) {
      if (V8_UNLIKELY(v8_flags.track_retaining_path)) {
        heap_->AddRetainingRoot(Root::kWriteBarrier, value);
      }
    }
  }
}

...

bool MarkingBarrier::WhiteToGreyAndPush(Tagged<HeapObject> obj) {
  if (marking_state_.TryMark(obj)) {
    current_worklist_->Push(obj);
    return true;
  }
  return false;
}

После того как весь граф объектов был промаркирован, те объекты, до которых дотянулся сборщик, оказываются помеченными черным статусом. Все остальные остаются белыми. Как и в случае с Minor Garbage Collection, живые объекты перемещаются в новое полупространство или в новую страницу old generation.

Продолжительность Major Garbage Collection линейна и зависит от количества живых объектов в old generation. Используя пошаговый алгоритм сборки мусора, V8 старается держать время работы Major Garbage Collection в пределах 6 ms.

Фрагментация страницы

После маркировки сборщик может оценить степень фрагментации данной страницы. Между живыми объектами, после очистки образуются пустые области. В зависимости от того скольки и какие объекты будут очищены, итоговая страница может получиться разной степени фрагментации.

На рисунке выше изображены примеры высоко фрагментированной (слева) и низко фрагментированной (справа) страниц. Движок V8 проводит оценку степени фрагментации и принимает решение о том, что делать дальше со страницей.

Compaction

В случае высокой фрагментации, сборщик копирует живые объекты в другую станицу которая еще не была скомпонована, параллельно сдвигая их, избавляясь от пустых областей. Этот процесс называется компоновкой (compaction). В результате получается дефрагментированная область памяти с живыми объектами. Мертвые же объекты очищаются вместе со старым полупространством. Однако, в памяти, зачастую бывает много долгоживущих объектов. Проводить компоновку каждой страницы может оказать слишком накладно. Поэтому, в случае низкой фрагментации сборщик идет по другому пути.

Sweeping

При низкой фрагментации, между живыми объектами остаются сравнительно большие области. Вместо того чтобы копировать и компоновать объекты, планировщик просто помещает адреса объединенных мертвых областей в специальный список free-list. Позже, когда движку понадобится аллоцировать новый объект в памяти, он, в первую очередь заглянет в free-list, и если там есть подходящее, место разместит новый объект в нем. Этот процесс и называется Sweeping.

Планирование Idle-задач

В статье Chromium. Отрисовка страницы с помощью Blink, CC и планировщика я подробно описывал процесс рендеринга Web-страницы и планировщик задач. Давайте коротко вспомним, о чем шла речь.

Движок Blink запускает процесс CC в отдельном потоке compositor thread. CC получает сигналы от разных систем Chromium и решает когда и что будет выводиться на экран. Если, например, инициировано начало анимации или скролл, СС посылает в главный поток сигнал о начале нового фрейма. Вместе с этим сигналом передается и дедлайн - время, до которого фрейм должен быть сформирован. Так как Chromium старается держать фреймрейт в районе 60 FPS, на один кадр приходится 1000/60 = ~16.6 ms. Ровно столько времени есть у Blink, чтобы поочередно выполнить задачи по обработке пользовательского ввода, части JavaScript и других приоритетных задач и обновить RenderTree. Если Blink не уложиться в заданное время, кадр будет задержан, что может сказать на визуальном пользовательском опыте (могут появиться скачки анимации, дрожание и т.д.). Однако, зачастую, движку требуется гораздо меньше времени. При маленьком количестве задач Chromium может справить с кадром за время <1 ms.

Оставшееся неиспользованное время называется временем простоя (Idle time). Однако, idle time, на самом деле, не совсем простой. Это тоже задача, такая же как и остальные задачи в очереди, только с низким приоритетом. Длительность этой задачи равно времени, оставшемуся до начала формирования следующего кадра. Если следующего кадра не предвидится, idle time выставляется в 50 ms. Число выбрано в связи с исследованиями, которые показывают, что ответ на пользовательский ввод в течение 100 ms воспринимается пользователем как мгновенный. Если по окончании 50 ms новых кадров не появилось, в очередь ставится новый idle time и так далее. Однако, если поступит сигнал о начале нового кадра, idle time будет прерван, не дожидаясь окончания времени.

Когда стартует idle time, могут начать выполняться задачи из специальной низкоприоритетной очереди. Такие задачи называются idle tasks. Чтобы не превысить время дедлайна, в задачу передается время окончания idle time. Ответственность самой задачи - быть завершенной до указанного срока. Задача может выполнить часть работы, которая уложиться в отведенное время, а оставшуюся часть - поставить в очередь новой задачей. Аналогично, если задача не может выполнить сколько-нибудь значимую работу за указанное время, она должна переставить себя в очередь новой задачей.

Idle tasks - прерогатива не только движка V8. Web-разработчику тоже доступен этот механизм. Браузерами предусмотрен метод Web API - requestIdleCallback, который ставит задачу в очередь idle tasks. Правда, на момент написания статьи, метод еще находится в процессе проработки и не поддерживается браузером Safari.

Планирование Garbage Collection для времени простоя

Выше мы говорили, что процесс сборки мусора может быть довольно нагрузочным. Чтобы не блокировать систему этой утилитарной операцией, V8 разбивает весь процесс на мелкие шаги, на каждый шаг, все равно может занимать до 5 ms процессорного времени. Чтобы сделать процесс максимально незаметным для всей остальной системы, V8 ставит задачи по сборке мусора именно в очередь idle tasks.

Minor Garbage Collection не может быть разбито на части о должна выполниться целиком за один раз.

Major Garbage Collection состоит из трех частей:

• начало пошаговой маркировки (incremental marking)
• несколько шагов маркировки
• завершение (finalization)

Каждый из этапов имеет свои показатели времени задержки и влияния на память. Хотя стадия начала маркировки, сама по себе является быстрой операцией, она ведет к нескольким шагам последующей маркировки и завершению, что может спровоцировать длинные паузы. Таким образом, старт маркировки может привести к ухудшению показателя времени задержки, зато оказывает большое влияние на показатель потребления памяти.

Запуск Minor Garbage Collection сокращает время задержки, но имеет сравнительно небольшое влияние на потребляемую память. Тем не менее регулярное выполнение Minor Garbage Collection позволяет предотвратить попадание объектов в стадию консервативной сборки мусора, которая выполняется вне времени простоя. Консервативная сборка мусора может быть запущена в критических ситуациях, например, при обнаружении нехватки выделенной памяти.

Таким образом, планирование должно планировщик должен балансировать между стартом слишком рано (и, как следствие, продвижению объектов в old generation слишком рано) и слишком поздно, что может привести к разрастанию размера young generation.

Планирование Minor Garbage Collection для времени простоя

Для осуществления Minor Garbage Collection требуется:

1. предикат, который скажет, можно ли выполнить Minor Garbage Collection в установленное время
2. механизм постановки idle task в Blink-планировщик для запуска в нужное время

V8 выполняет idle-time Minor Garbage Collection, тольк если её ожидаемое время выполнения укладывается в дедлайн пекущего idle-пероида и, при этом, есть достаточное количество объектов в young generation.

Пусть H - общий размер объектов в байтах в young generation.

S' - средняя скорость обработки предыдущих Minor Garbage Collections в байтах в секунду

T - дедлайн текущего idle-периода в секундах

T' - средний дедлайн idle task в секундах

V8 выполнит Minor Garbage Collection, если:

max(T' * S' - N, Hmin) < H <= S' * T

где N - ожидаемое количество байт, которые будут аллоцированы перед следующей idle task

Hmin - минимальный размер young generation, гарантирующий сборку мусора

(T' * S' - N) < H можно переписать, как (T' * S') < (H + N), что оценивает, будет ли следующий Minor Garbage Collection больше среднего дедлайна idle-задачи. Если больше - Minor Garbage Collection должна быть выполнена в текущем idle-периоде. Если меньше - в young generation пока еще недостаточно объектов для эффективной работы.

В целях запроса idle time для Minor Garbage Collection от Blink-планировщика, V8 размещает аварийные маркеры каждые N байт в новом generation. Когда очередная аллокация пересекает аварийный маркер, она вызывает runtime-функцию V8, которая публикует idle task в Blink-планировщик.

Экспериментальным путем установлено, что N = 512 Kb достаточно, чтобы не снижать пропускную способность, при этом достаточно мало, чтобы V8 имел несколько возможностей опубликовать idle task.

Планирование Major Garbage Collection для времени простоя

Процесс запуска пошаговой маркировки мы рассмотрим чуть ниже. Пока представим, что она уже запущена. Сразу, как только произошел запуск, V8 ставит idle task в Blink-планировщик. Задача выполняет, непосредственно, сам процесс маркировки.

Взяв за основу среднюю скорость маркировки, idle task пытается достигнуть максимального объема работы, возможного в текущем idle-периоде.

Пусть Tidle - дедлайн idle-задачи в секундах,

M - скорость маркировки в байтах в секунду.

Тогда,

Tidle * M - количество байт, которые будут промаркированы в этой idle task.

Idle task итеративно переставляет себя в очередь до тех пор вся Heap не будет промаркирована. После этого V8 ставит задачу на завершение Major Garbage Collection. Процесс завершения будет выполнен, если оценочное время этой задачи укладывается в дедлайн. V8 определяет время процесса завершения на основе скорости предыдущих задач на завершение.

Memory Reducer

Memory reducer - это контроллер, который пытается высвободить память в неактивных Web-страницах.

Major Garbage Collector включается в работу, когда куча достигает определенного заданного размера. Этот размер рассчитывается и выставляется в конце предыдущей Major Garbage Collection, на основе коэффициента увеличения кучи f и общего размера живых объектов в old generation

limit' = f * size

Следующая Major Garbage Collection ставится в очередь, когда количество байт, аллоцированных с момента предыдущей сборки, превысит этот предельный размер limit' - size.

Все хорошо, пока Web-страница стабильно выделяет память. Однако, если Web-страница ушла в простой, память выделяться перестает, а значит, заданный предел не будет достигнут и Major Garbage Collection не запустится.

Зачастую, многие Web-страницу демонстрируют высокую интенсивность выделения памяти в момент загрузки, посколько они инициализируют свои внутренние структуры данных. Через несколько секунд или минут после загрузки, Web-страница часто становится неактивной, при этом в памяти находится большое количество объектов, которые уже не нужны. Что может приводить к снижению скорости выделения памяти и, как следствие, к снижению скорости выполнения JavaScript кода.

На диаграмме выше приведен пример планирования Major Garbage Collection. Первая сборка случается в момент времени t1, так как был достигнут предельный размер кучи. V8 устанавливает новое значение предела на основе коэффициента увеличения кучи и размера кучи. Следующий вызов Major Garbage Collection произойдет в момент t2, когда будет достигнут новый предел, потом, в момент t3 и так далее. Пунктирной линией показан размер кучи, каким бы он был без memory reducer.

Таким образом, memory reducer может запустить Major Garbage Collection, не дожидаясь лимита аллоцирования. Однако, бесконтрольное снижение предела может привести к ухудшению показателя задержки. Поэтом команда V8 разработала эвристический метод, который полагается не только на idle time, предоставленным планировщиком Blink между кадрами, но и на то, является ли страница неактивной в данный момент. Индикатором того, активна страница или нет, являются скорость аллоцирования JavaScript и частота вызовов JavaScript из браузера. Когда обе скорости падают ниже заданного порога, страница считается неактивной.

На рисунке показаны состояния и переходы memory reducer. В состоянии done контроллер ожидает сигнала о том, что было выполнено достаточное количество выделений, чтобы гарантировать запуск сборщика мусора. В этот момент применяется, так называемый non-idle Major Garbage Collection, который запускается по достижении лимита выделения, что является сигналом для перехода в состояние wait(i). В этом состоянии контроллер ждет, когда Web-страница станет неактивной. Когда это происходит, запускает пошаговая маркировка и переход в состояние run(i), до тех пор, пока Major Garbage Collection не завершит работу. Далее, если расчеты показывают, что еще одна Major Garbage Collection, вероятно, позволит высвободить еще памяти, контроллер переходит в состояние wait(i+1). В противном случае, он вернется в исходное состояние done.

Важнейшей частью контроллера является хорошо настроенный порог частоты аллоцирования. Изначально, этот порог был фиксированной величины. В целом, такой вариант показывал себя неплохо на Desktop устройствах. Однако на более медленных системах, например, мобильных, это не работает. Поэтому разработчикам пришлось сделать динамическую адаптацию под разное аппаратное обеспечение.

Пусть g - скорость Major Garbage Collection,

a - частота аллоцирования.

Тогда

μ = g/(g+a)

Соотношение μ можно рассматривать как использование мутатора во временном интервала с настоящего момента до следующей Major Garbage Collection. Предполагая, что текущая частота аллоцировани остается постоянной и куча в данный момент пуста:

Tmu = limit/a               (mutator time)

  Tgc = limit/g             (GC time)
  
    μ = Tmu /(Tmu + Tgc )   (mutator utilization)
    
      = (limit /a)/(limit /a + limit /g)
      
      = g/(g + a)

Это дает нам условие для неактивной скорости распределения: μ ≥ µinactive , где µinactive - фиксированное значение.

В коде V8 µinactive имеет значение0.993.

bool Heap::HasLowOldGenerationAllocationRate() {
  double mu = ComputeMutatorUtilization(
      "Old generation",
      tracer()->OldGenerationAllocationThroughputInBytesPerMillisecond(),
      tracer()->CombinedMarkCompactSpeedInBytesPerMillisecond());
  const double kHighMutatorUtilization = 0.993;
  return mu > kHighMutatorUtilization;
}

Мои телеграмм-каналы:

English version: https://blog.frontend-almanac.com/v8-garbage-collection

Парсинг Web-страницы

Давайте, для начала вспомним, как вообще происходит рендеринг Web-страницы.

Получив документ HTML, браузер производит его парсинг. Так как HTML изначально разрабатывался совместимым с традиционной структурой XML, никаких, интересных для нас особенностей на этом этапе нет. В результате парсинга браузер получает иерархическое дерево объектов - DOM (Document Object Model).

По мере прохождения по структуре HTML и парсинга его в DOM, браузер встречает такие элементы, как стили и JS-скрипты (как встроеные, так и в виде удаленных ресурсов). Такие элементы требуют дополнительной обработки. JS-скрипт парсится JavaScript-движком в структуру AST, и далее раскладывается в память в виде внутренних объектов самого движка. Стили же выстраиваются в каскадное дерево CSSOM. В это же дерево будут добавлены и inline-стили элементов.

Получив DOM и CSSOM, браузер теперь имеет возможность произвести все необходимые расчеты позиционирования и отображения элементов и, как результат, составить одно общее дерево Render Tree, на основании которого и будет производиться отрисовка графики непосредственно на экране.

Отрисовка Web-страницы

На сегодняшний день, большинство браузеров являются многопоточными. Не исключение и браузеры на основе движка Chromium.

Blink

За всё, что связано с отрисовкой контента в табе браузера отвечает отдельная система под названием Blink. Вообще, Blink - это большой и сложный движок, в обязанности которого входят такие функции как реализация спецификации HTML в части DOM, CSS и Web IDL, интеграция движка V8 и запуск JavaScript-кода, отрисовка графики на экране (интеграция движка Skia), запрос сетевых ресурсов, обработка операций ввода, выстраивание деревьев (DOM, CSSOM, Render Tree), расчет стилей и позиционирования и еще много чего другого, включая Chrome Compositor (CC).

Сам движок не является "коробочным" решением и не может быть запущен самостоятельно. Это, своего рода, форк компонента WebCore движка WebKit.

Blink используется в таких платформах, как Chromium, Android WebView, Opera, Microsoft Edge и многих других Chromium-based браузерах.

Chrome Compositor (CC)

В кодовой базе Chromium этот механизм находится в директории сс/. Так исторически сложилось, что аббревиатуру СС расшифровывают как Chrome Compositor ("компоновщик"), хотя, на сегодняшний день, он компоновщиком, как таковым не является. Дана Дженсенс (danakj) даже предложила альтернативный вариант названия - Content Collator ("обобщитель" или "сопоставитель" контента).

СС запускается движком Blink и может работать как в однопоточном, так и в многопоточном режимах. Работа СС требует отдельной статьи, здесь мы не будем подробно разбирать все механики системы. Отметим только, что основными сущностями, которыми оперирует СС являются слои и деревья слоев. Эти сущности доступны из CC в качестве API. Слои (Layer) могут быть множества разных видов, например, слой изображения, слой текстур, поверхностный слой и др. Задача клиент CC (в нашем случае, клиентом для СС является Blink) собрать свое дерево слоев (LayerTreeHost) и сообщить СС о том, что оно готово и может быть отрисовано. Такой подход позволяет сделать процесс формирования итоговой композиции атомарным.

Принципиальная схема рендеринга

Chromium является многопоточным движком. Под множество конкретных операций, связанных с рендерингом, выделяются отдельные поток. Основными потоками, условно, можно считать main thread и compositor thread.

Main thread - основной поток, в котором работает Blink. Именно здесь составляются конечные RenderTree и LayerTreeHost. Здесь же обрабатываются сгруппированные операции ввода и исполняется JavaScript-код. После того, как все необходимые операции и расчеты произведены, Blink сообщит СС о том, что деревья готовы к отрисовке.

Compositor thread отвечает за работу CC, т.е. за планирование задач рендеринга и непосредственную отрисовку на экране.

Blink стремиться отображать графику с частотой 60 FPS (60 кадров в секунду), т.е. один кадр должен быть выведен на экран примерно за 16.6 ms. Такой фреймрейт считается оптимальным для восприятия человеческим глазом. Меньшая частота может приводить к неравномерной анимации, скачкам и дрожаниям графики.

На схеме выше изображена упрощенная схема рендеринга. Как я же упоминал, СС запускается в отдельном потоке. В определенный момент он решает, что наступило время инициировать рендеринг кадра. СС подает сигнал в главный поток о начале нового фрейма. Blink получает сигнал в главном потоке и выполняет необходимые запланированные операции, такие как пакетная обработка ввода, исполнение JavaScript-кода (точнее, JavaScript-задач из Event Loop) и обновление RenderTree. После того, как RenderTree готово, движок производит соответствующие изменения в LayerTreeHost (в его временной копии) и отправляет сигнал commit в СС, где тот, в свою очередь забирает все расчеты и отправляет задачи на отрисовку графики на конечном устройстве используя API соответствующих графических библиотек ОС (таких как OpenGL и DirectX).

На весь этот процесс отведено окно в 1000/60 = ~16.6 ms. Если движок не успеет выполнить все необходимые операции за это время, кадр будет задержан, что может привести к снижению фреймрейта. Поэтому, крайне важной задачей для Blink является подсчет и прогнозирование времени выполнения предстоящих задач. Зная, сколько времени займет та или иная операция, движок имеет возможность взять в работу только то, что успеет выполнить за отведенное время, остальные операции будут отложены до следующего раза.

Существуют, так же, операции, в которых не производятся специфические расчеты и не задействован JavaScript, например скроллинг. Такие операции CC может выполнить самостоятельно в своем потоке, тем самым не блокируя основной поток. В то же время, например, анимация требует интенсивных расчетов на стороне основного потока, на протяжении большого количества кадров. Если основной поток занят другими приоритетными задачами, в случае большого объема часть операций по анимации может быть отложена или задержана.

Планировщик задач

Планировщик задач предназначен для снижения вероятности задержек в обновлении кадра. Запускается он в основном потоке. Каждая задача ставится механизмами движка в одну из очередей, специфичных для этого типа задачи. Задачи СС попадают в свою очередь, операции по обработке ввода - в свою, выполнение JavaScript-кода - в свою, а процессы по загрузке страницы - в свою.

Задачи внутри очереди выполняют в том порядке, в котором они туда попали (вспоминаем Event Loop). Однако, из какой именно очереди выполнить следующую задачу, выбирает планировщик, который волен решать это динамически, меняя приоритет очереди по своему усмотрению. Когда и какой установить приоритет, планировщик решает на основании получаемых сигналов от множества разных систем. Так, если страница находится еще на этапе загрузки, в приоритете будут сетевые запросы и парсинг HTML. А если зафиксировано событие touch, планировщик временно повысит приоритет операций ввода, в течение следующих 100 ms, дабы корректно распознать возможные жесты. Предполагается, что именно в этот временной интервал следующие возможные события могут оказаться операциями скролла, тапа, зума и т.д.

Обладая полной информацией об очередях и задачах в них, а так же о сигналах от других компонентов, планировщик имеет возможность рассчитать примерное время простоя системы. Чуть выше мы рассматривали пример рендеринга кадров. Вместе с сигналом от CC о начале отрисовки кадра посылается, так же, предполагаемое время следующего кадра, если кадр имеется (+16.6ms). Зная, есть ли необходимые для отрисовки кадра, операции ввода и какой JavaScript-код требуется выполнить, планировщик может прикинуть продолжительность выполнения этих задач. А зная время следующего кадра, может, так же, рассчитать время, так называемого простоя (Idle time). На самом деле, этот период является не совсем простоем. Он может быть использован для выполнения ряда низко-приоритетных задач (Idle tasks). Такие задачи помещаются в свою очередь и выполняются порциями, только после того, как другие очереди опустели, и в ограниченный промежуток времени. В частности, эту очередь активно использует сборщик мусора. Именно здесь происходит большая часть работы по маркировке мертвых объектов и дефрагментации памяти. Принудительно, с высоким приоритетом, консервативный сборщик запускается только в крайних случаях, например, при обнаружении нехватки памяти. Подробнее об этом поговорим в статье Сборка мусора в V8.

Регулярность частоты кадров

Я уже говорил, что Chromium стремиться достичь частоты кадров в 60 FPS. Для достижения этой цели движок оснащен планировщиком, СС и множеством других систем. Однако, на практике, добиться идеальной регулярности - задача практически невыполнимая, так как на процесс может влиять большое количество непредвиденных ситуаций, как внутренних (одна или несколько задач могут отрабатывать дольше, чем оценил планировщик), так и внешних (например, загруженность CPU или GPU другими процессами).

Примерно вот так выглядит скролл страницы https://www.google.com/chrome в трассировщике. Далеко не все кадры анимации смогли уложиться в отведенное окно 16.6 ms.

Более того, кроме задержек в отрисовке, часть кадров и вовсе может быть отклонена самим движком Blink. Такое нередко случается, например, во время анимации. Причин сброса кадров анимации существует целое множество. Blink предусматривает таких причин порядка двадцати (версия Chromium на момент написания статьи 124.0.6326.0)

/third_party/blink/renderer/core/animation/compositor_animations.h#65

enum FailureReason : uint32_t {
  kNoFailure = 0,
  
  // Cases where the compositing is disabled by an exterior cause.
  kAcceleratedAnimationsDisabled = 1 << 0,
  kEffectSuppressedByDevtools = 1 << 1,
  
  // There are many cases where an animation may not be valid (e.g. it is not
  // playing, or has no effect, etc). In these cases we would never composite
  // it in any world, so we lump them together.
  kInvalidAnimationOrEffect = 1 << 2,
  
  // The compositor is not able to support all setups of timing values; see
  // CompositorAnimations::ConvertTimingForCompositor.
  kEffectHasUnsupportedTimingParameters = 1 << 3,
  
  // Currently the compositor does not support any composite mode other than
  // 'replace'.
  kEffectHasNonReplaceCompositeMode = 1 << 4,
  
  // Cases where the target element isn't in a valid compositing state.
  kTargetHasInvalidCompositingState = 1 << 5,
  
  // Cases where the target is invalid (but that we could feasibly address).
  kTargetHasIncompatibleAnimations = 1 << 6,
  kTargetHasCSSOffset = 1 << 7,
  
  // This failure reason is no longer used, as multiple transform-related
  // animations are allowed on the same target provided they target different
  // transform properties (e.g. rotate vs scale).
  kObsoleteTargetHasMultipleTransformProperties = 1 << 8,
  
  // Cases relating to the properties being animated.
  kAnimationAffectsNonCSSProperties = 1 << 9,
  kTransformRelatedPropertyCannotBeAcceleratedOnTarget = 1 << 10,
  kFilterRelatedPropertyMayMovePixels = 1 << 12,
  kUnsupportedCSSProperty = 1 << 13,
  
  // This failure reason is no longer used, as multiple transform-related
  // animations are allowed on the same target provided they target different
  // transform properties (e.g. rotate vs scale).
  kObsoleteMultipleTransformAnimationsOnSameTarget = 1 << 14,
  
  kMixedKeyframeValueTypes = 1 << 15,
  
  // Cases where the scroll timeline source is not composited.
  kTimelineSourceHasInvalidCompositingState = 1 << 16,
  
  // Cases where there is an animation of compositor properties but they have
  // been optimized out so the animation of those properties has no effect.
  kCompositorPropertyAnimationsHaveNoEffect = 1 << 17,
  
  // Cases where we are animating a property that is marked important.
  kAffectsImportantProperty = 1 << 18,
  
  kSVGTargetHasIndependentTransformProperty = 1 << 19,
  
  // When adding new values, update the count below *and* add a description
  // of the value to CompositorAnimationsFailureReason in
  // tools/metrics/histograms/enums.xml .
  // The maximum number of flags in this enum (excluding itself). New flags
  // should increment this number but it should never be decremented because
  // the values are used in UMA histograms. It should also be noted that it
  // excludes the kNoFailure value.
  kFailureReasonCount = 20,
};

Из всего набора, наиболее частыми причинами являются отсутствие визуального эффекта анимации (kCompositorPropertyAnimationsHaveNoEffect), когда результат анимации не приводит к изменениям в графике и, соответственно, не требует перерисовки.

Так же, к сбросу кадра может привести не поддерживаемое CSS-свойство (kUnsupportedCSSProperty). Такое может случиться, если движок не понимает, как пересчитать то или иное свойство, даже если само это свойство выглядит вполне валидным.

<style>
  #block1 {
    animation: expand 1s linear infinite;
  }

  @keyframes expand {
    to {
      height: auto;
    }
  }
</style>

<div id="block1"></div>

В примере выше движок не знает, как ему высчитать высоту блока, так как конечное значение не определено и не может быть рассчитано на этапе анимации. В результате, движок сбросит первый кадр анимации, а дальнейшие даже не будет пытаться посчитать, так как в этом нет никакого смысла.

В трассировщике, в этом случае мы нейдем запись, вроде

{"args":{"data":{"compositeFailed":8224,"unsupportedProperties":["height"]}},"cat":"blink.animations,...

Всё это приводит к тому, что реальное количество кадров, отрисованных за секунду, может быть меньше 60-ти.

Расхождение как показатель регулярности частоты кадров

Помимо среднего фреймрейта, в анимированных приложениях важна, так же и регулярность отрисовки. Если приложение рендерит 60 (или близко к тому) кадров в секунду, но размер промежутков между кадрами сильно расходится, пользователь может наблюдать скачки или дрожание на экране. Существует множество методик оценки этого явления, от простого замера самого длинного кадра, до расчета расхождения в длинах кадров. У каждого метода есть свои плюсы, однако, большинство покрывает только ряд случаев и не учитывает временной порядок кадров. В частности, они не способны различить ситуации, когда два сброшенных кадра находятся рядом, и когда далеко.

В связи с этим, разработчики Google предложили свою методику оценки регулярности кадров. Метод основан на расхождении в последовательности длительностей кадров, по аналогии с математическим методом Monte Carlo integration.

Теоретическая база метода была представлена на 37-ой ежегодной конференции ACM SIGPLAN в 2016-м году.

На рисунке ниже представлен пример расхождения регулярности кадров.

Каждая линия представляет набор временных меток. Черными точками обозначены отрисованные кадры. Белыми - сброшенные. Расстояние между точками - 1 VSYNC, который равен 16.6 ms для 60-герцовой частоты обновления. Итоговые расхождения расчитываются в VSYNC-интервалах:

D(S1) = 1
D(S2) = 2
D(S3) = 2
D(S4) = 25/9
D(S5) = 3

В идеальном случае (S1) расхождение равно интервалу между кадрами (1 VSYNC). Если один из кадров был сброшен (S2), расхождение будет равно наибольшему расстоянию между двумя отрисованными кадрами. В случае S2 наибольшее расстояние будет между точками 2 и 3 и равно 2 VSYNC. Тоже самое будет и в случае, если имеется два сброшенных кадра, но далеко друг от друга (S3). Это обусловлено тем, что задача метода - определить наихудший случай производительности, а не средний, что отражено в расчетных формулах. Поэтому метод комбинируется со средней продолжительностью кадра, чтобы отличить один пропущенный кадр от серии повторяющихся пропусков (последнее, очевидно, хуже). В случае S4 мы наблюдаем два сброшенных кадра, которые находятся близко друг к другу. Такие кадры составляют уже единую потерянную область и расхождение здесь составить 25/9 (~2.7) VSYNC. Еще хуже дела обстоят в случае S5, так как между двумя сброшенными кадрами не было ни одного отрисованного. Наибольшее расстояние между отрисованными кадрами здесь будет между точками 2 и 4, что составляет 3 интервала (3 VSYNC).

Мои телеграмм-каналы:

English version: https://blog.frontend-almanac.com/chromium-rendering

Основные понятия

Чтобы разобраться в механизме итерации, давайте взглянем на следующие интерфейсы.

interface Iterable {
  [Symbol.iterator]: () => Iterator;
}

interface Iterator {
  next: () => IteratorResult;
  
  return?: (value?: any) => IteratorResult;
  
  throw?: (exception?: any) => IteratorResult;
}

interface IteratorResult {
  done?: boolean;
  value?: any;
}

Итак, объект считается итерируемым, если он реализует интерфейс Iterable. Другими словами, если он содержит метод [Symbol.iterator] - функцию, возвращающую, непосредственно, объект-итератор.

Итератор - это простой (ordinary) объект, который содержит метод next(). Остальные два метода в интерфейсе Iterator не являются обязательными. Метод next() обязан вернуть объект IteratorResult.

Суть итерируемости заключается в том, что такой объект может быть перебран циклами for..of и for..in.

for (const item of [1, 2, 3]) {
    console.log(item);
}
// 1
// 2
// 3

Встроенные итераторы

Механизм итераций является одним из самых широко используемых в JavaScript. Язык буквально пронизан встроенными итерируемыми объектами. К ним относятся: Array, TypedArray, Map, Set, WeakMap, WeakSet, String.

// Array
for (const item of new Array(1, 2, 3)) {
    console.log(item);
}
// 1
// 2
// 3

// TypedArray
for (const item of new Int8Array(3)) {
    console.log(item);
}
// 0
// 0
// 0

// Map
for (const item of new Map([[1, 'one'], [2, 'two'], [3, 'three']])) {
    console.log(item);
}
// [1, 'one']
// [2, 'two']
// [3, 'three']

// Set
for (const item of new Set([1, 2, 3])) {
    console.log(item);
}
// 1
// 2
// 3

// String
for (const item of "abc") {
    console.log(item);
}
// a
// b
// c

Кроме JavaScript, некоторые объекты Web API так же реализуют интерфейс Iterable. Например, в стандарте DOM, примерами таких объектов являются NodeList и DOMTokenList.

// NodeList
for (const item of document.querySelectorAll("div")) {
    console.log(item);
}
// Node
// Node
// ...

// DOMTokenList
const block = document.createElement("div");
block.classList.add("classA", "classB")

for (const item of block.classList) {
    console.log(item)
}
// classA
// classB

Собственные итераторы

По мимо встроенных итерируемых объектов, существует возможность создать собственный. Для этого достаточно просто реализовать интерфейс Iterable, соблюдая протокол итерации.

Итак, как уже было сказано выше, объект считается итерируемым, если его прототип содержит метод [Symbol.iterator](). В противном случае, при попытке пропустить такой объект через цикл, будет сгенерировано исключение.

const obj = {};

for (const item of obj) {
    console.log(item);
}

// Uncaught TypeError: obj is not iterable

Теперь добавим метод-итератор в наш объект.

const obj = {
    [Symbol.iterator]: () => {},
};

for (const item of obj) {
    console.log(item);
}

// Uncaught TypeError: Result of the Symbol.iterator method is not an object

Теперь, формально, объект считается итерируемым, но пропустить его через цикл в таком виде все равно не получится, так как метод-итератор не возвращает объект, реализующий интерфейс Iterator, как того требует протокол.

next()

Согласно протоколу, итератор должен быть простым объектом, содержащим, как минимум, один метод next(). Сам метод next() может принимать аргументы, но строго обязательства в этом нет. Спецификация ECMA-262 гарантирует, что все встроенные пользователи итерируемых объектов вызывают этот метод без аргументов. Однако, в редких случаях, аргументы могут быть полезны при ручном вызове итератора.

const obj = {
    [Symbol.iterator]: () => {
        return {
            next: () => {},
        };
    },
};

for (const item of obj) {
    console.log(item);
}

// Uncaught TypeError: Iterator result undefined is not an object

В примере выше мы добавили метод next(), но сам этот метод все еще не возвращает правильный IteratorResult.

IteratorResult - это, так же простой объект, имеющий два свойства, done и value.

Свойство done является булевым и выражает завершение процесса итерации. Другими словами, пока объект может итерироваться дальше, его итератор возвращает done: false, достигнув последнего шага итерации, итератор должен вернуть done: true, что будет являться сигналом для пользователя итерируемого объекта (например, цикла) к завершению процесса (выходу из цикла).

Свойство value - непосредственно значение, ассоциированное с данным шагом итерации. Ограничений на формат возвращаемого значения нет.

Как я только что упоминал, если итератор вернул done: true, итерирование будет считаться завершенным, следующий шаг итерации не случится, а значит, в значении value, в этом случае, смысла больше нет, соответственно, и передавать его вместе с done: true, не обязательно.

Стоит сказать, что спецификация ECMA-262 к вопросу итераторов подошла крайне либерально. На самом деле, возвращать ни свойство done, ни свойство value вовсе не обязательно. Для обоих предусмотрены значения по умолчанию (false и undefined соответственно). Т.е. фактически, чтобы наш итерируемый объект наконец заработал, итератору достаточно вернуть просто пустой объект.

const obj = {
    [Symbol.iterator]: () => {
        return {
            next: () => {
                return {}; // { done: false, value: undefined }
            },
        };
    },
};

for (const item of obj) {
    console.log(item);
}

// Осторожно!!! Данный код ведет в бесконечный цикл

Однако, пользы от такого итератора мало. Более того, так как итератор никогда не вернет done: true, весь код уйдет в бесконечный цикл.

Итак, давайте, все таки, опишем функциональный итератор по всем правилам.

const obj = {
    [Symbol.iterator]: () => {
        let i = 0;
        
        return {
            next: () => {
                return {
                    done: i >= 3,
                    value: i++,
                };
            },
        };
    },
};

for (const item of obj) {
    console.log(item);
}

// 0
// 1
// 2

В данном примере мы последовательно возвращаем числа 0, 1, 2. Выход из цикла осуществляется по достижении i === 3.

return()

В ряде случаев, процесс итерации может быть принудительно остановлен тем или иным образом из вне. В таком случае, пользователь итерируемого объекта должен вызвать метод итератора return(), если он существует.

const obj = {
    [Symbol.iterator]: () => {
        let i = 0;
        
        return {
            next: () => {
                return {
                    done: i >= 3,
                    value: i++,
                };
            },
            
            return: () => {
                console.log("Return", i);
                return {
                    done: i >= 3,
                    value: i,
                }
            }
        };
    },
};

for (const item of obj) {
    console.log(item);
    
    if (item === 1) {
        break;
    }
}
// 0
// 1
// Return 2

Как и метод next(), метод return() обязан вернуть объект IteratorResult. Данный метод является, своего рода, колбэком в момент принудительного прерывания итерации. Предполагается, что здесь могут быть выполнены специфические операции, необходимые по звершении процесса. Например, отвязка прослушивателей или очистка памяти.

throw()

Еще один метод-колбэк по аналогии с return(). Суть его в том, чтобы дать возможность пользователю итерируемого объекта сообщить о найденой ошибке. Среди встроенных пользователей JavaScript нет таких, которые могут вызвать этот метод в какой-либо ситуации. Однако, данный колбэк может быть вызван вручную.

Протокол позволяет передать в метод throw() аргумент, который, предлагается использовать в качестве ссылки на исключение, хотя формально, ограничений, как на количество, так и на типы аргументов - нет.

Будучи вызванным, метод throw() должен "выкинуть" переданное ему исключение, дабы остановить дальнейший процесс итерации. Опять же, такое поведение является рекомендованным и ожидаемым, но не обязательным. Автор итератора вправе самостоятельно определить дальнейшую логику.

const obj = {
  [Symbol.iterator]: () => {
    let i = 0;
    
    return {
      next: () => {
        return {
          done: i >= 3,
          value: i++,
        };
      },
      
      throw: (exception) => {
        console.log("Thrown:", exception);
        
        if (exception) {
          throw exception;
        }
        
        return {
          done: true,
        };
      },
    };
  },
};

for (const item of obj) {
  console.log(item);
  
  if (item === 1) {
    obj[Symbol.iterator]().throw(`Reached ${item}`);
  }
}

// 0
// 1
// Thrown: Reached 1
// Uncaught Reached 1

Чаще всего, метод throw() применяется в асинхронных итераторах в паре с генераторами. Об этом далее.

Ручной вызов итератора

Как уже стало понятным, основным пользователем итерируемых объектов являются конструкции for..of и for..in. Эти встроенные пользователи самостоятельно реализуют протокол итерации. Однако, иногда есть необходимость в создании своего собственного пользователя или, просто в проходе процесса итерации в ручном режиме. Как мы видели в последнем примере, к итератору можно обратиться напрямую и пройти весь цикл самостоятельно.

const obj = {
  [Symbol.iterator]: () => {
    let i = 0;
    
    return {
      next: () => {
        return {
          done: i >= 5,
          value: i++,
        };
      },
      
      return: () => {
        return {
          done: true,
          value: i,
        };
      },
      
      throw: (exception) => {
        if (exception) {
          throw exception;
        }
        
        return {
          done: true,
        };
      },
    };
  },
};

// получаем итератор посредством вызова метода-итератора
const iterator = obj[Symbol.iterator]();

// первый шаг итреации
let result = iterator.next();
console.log(result.value);

// остальные шаги будут вызываться в цикле, пока итератор
// не вернет `done: true`
while (!result.done) {
  const result = iterator.next();
  console.log(result.value);
  
  if (isSuccess(result.value)) {
    // по необходимости, мы можем остановить процесс итареции
    iterator.return();
    break;
  }
  
  if (isFailed(result.value)) {
    // или выкинуть исключение
    iterator.throw(new Error("failed"));
  }
}

Самоитерируемые объекты

Мы уже познакомились с двумя понятиями: итерируемый объект (Iterable), и итератор (Iterator). До сих пор мы рассматривали обе сущности в отдельности. Следующая техника позволяет объединить все в один самоитерируемый объект.

const obj = {
  i: 0,
  
  [Symbol.iterator]() {
    return this;
  },
  
  next() {
    return {
      done: this.i >= 3,
      value: this.i++,
    };
  },
  
  return() {
    return {
      done: true,
      value: this.i,
    };
  },
  
  throw(exception) {
    if (exception) {
      throw exception;
    }
    
    return {
      done: true,
    };
  },
};

for (const item of obj) {
  console.log(item);
}

В этом примере, в методе-итераторе мы, в качестве итератора вернули ссылку на сам итерируемый объект, таки образом, obj одновременно является и итератором и итерируемым объектом.

Похожим образом может выглядеть и итерируемый класс.

class Obj {
  i = 0;
  
  [Symbol.iterator]() {
    return this;
  }
  
  next() {
    return {
      done: this.i >= 3,
      value: this.i++,
    };
  }
  
  return() {
    return {
      done: true,
      value: this.i,
    };
  }
  
  throw(exception) {
    if (exception) {
      throw exception;
    }
    
    return {
      done: true,
    };
  }
}

const obj = new Obj();

for (const item of obj) {
  console.log(item);
}

Асинхронные итераторы

До сих пор мы говорили только о синхронных итераторах. В июне 2018-го была опубликована 9-я редакция спецификации ECMA-262. В этой версии были анонсированы асинхронные итераторы и протокол AsyncIterator.

По своей сути, асинхронный итератор мало чем отличается от синхронного. Давайте взглянем на следующие интерфейсы.

interface AsyncIterable {
  [Symbol.asyncIterator]: () => AsyncIterator;
}

interface AsyncIterator {
  next: () => Promise<IteratorResult>;
  
  return?: (value?: any) => Promise<IteratorResult>;
  
  throw?: (exception?: any) => Promise<IteratorResult>;
}

Итак, основная разница между синхронным и асинхронным итерируемыми объектами в том, что асинхронный должен иметь метод-итератор [Symbol.asyncIterator], (вместо [Symbol.iterator], как в случае с синхронным). А в качестве возвращаемых значений методами next(), return() и throw() ожидается Promise.

Сами по себе асинхронные итераторы небыли бы так удобны в использовании, если бы спецификация не предусмотрела новую структуру - асинхронный цикл for..await..of.

const obj = {
  [Symbol.asyncIterator]: () => {
    let i = 0;
    
    return {
      next: () => {
        return Promise.resolve({
          done: i >= 3,
          value: i++,
        });
      },
      
      return: () => {
        return Promise.resolve({
          done: true,
          value: i,
        });
      },
      
      throw: (exception) => {
        if (exception) {
          return Promise.reject(exception);
        }
        
        return Promise.resolve({
          done: true,
        });
      },
    };
  },
};

(async () => {
  for await (const item of obj) {
    console.log(item);
    
    if (item === 1) {
      await obj[Symbol.asyncIterator]().throw(`Reached ${1}`);
    }
  }
})();

Асинхронные генераторы

Еще одним важным нововведение 9-ой редакции ECMA-262 стали асинхронные генераторы, тесно связанные с асинхронными итераторами.

Простой асинхронный генератор может выглядеть следующим образом.

async function* gen() {
  yield 0;
  yield 1;
  yield 2;
}

(async () => {
  for await (const item of gen()) {
    console.log(item);
  }
})();

// 0
// 1
// 2

Асинхронный генератор реализует протокол AsyncIterator, а потому, мы можем пользоваться всеми доступными методами итератора вручную.

async function* gen() {
  yield 0;
  yield 1;
  yield 2;
}

const iterator = gen();

(async () => {
  console.log(await iterator.next());
  console.log(await iterator.next());
  console.log(await iterator.next());
  console.log(await iterator.next());
})();

// {value: 0, done: false}
// {value: 1, done: false}
// {value: 2, done: false}
// {value: undefined, done: true}

В том числе, остановить процесс итерации.

async function* gen() {
  yield 0;
  yield 1;
  yield 2;
}

const iterator = gen();

(async () => {
  console.log(await iterator.next());
  console.log(await iterator.return("My return reason"));
})();

// {value: 0, done: false}
// {value: 'My return reason', done: true}

Или выкинуть исключение.

async function* gen() {
  yield 0;
  yield 1;
  yield 2;
}

const iterator = gen();

(async () => {
  console.log(await iterator.next());
  console.log(await iterator.throw("My error"));
})();

// {value: 0, done: false}
// Uncaught (in promise) My error

Async-from-Sync итератор

Async-from-Sync итератор - это асинхронный итератор, полученный из синхронного посредством абстрактной операции CreateAsyncFromSyncIterator. Напомню, абстрактная операция - это внутренний механизм языка JavaScript. В обычно режиме такие операции не доступны внутри исполняемого контекста. Однако, например, движок V8 дает возможность воспользоваться этими операциями при включенном флаге --allow-natives-syntax.

> v8-debug --allow-natives-syntax iterator.js

// iterator.js
const syncIterator = {
  [Symbol.iterator]() {
    return this;
  },
  
  next() {
    return {
      done: true,
      value: Promise.resolve(1),
    };
  },
};

const asyncIterator = %CreateAsyncFromSyncIterator(syncIterator);

console.log(asyncIterator);
// [object Async-from-Sync Iterator]

console.log(asyncIterator[Symbol.asyncIterator]);
// function [Symbol.asyncIterator]() { [native code] }

Как мы можем видеть, эта абстрактная операция преобразует синхронный итератор в асинхронный. Как я уже говорил, в обычном исполняемом контексте мы не можем вызвать абстрактную операцию. Это делает сам движок в тех местах, где требуется. А требуется это, согласно спецификации, в одном конкретном случае:

• Текущее окружение является асинхронным
• Итерируемый объект не имеет метода [Symbol.asyncIterarot]
• Итерируемый объект имеет метод [Symbol.iterator]

Проще всего продемонстрировать этот процесс можно на генераторах.

function* syncGen() {
  yield 1;
  yield 2;
  yield Promise.resolve(3);
  yield Promise.resolve(4);
  yield 5;
}

for (const item of syncGen()) {
  console.log(item);
}

// 1
// 2
// Promise
// Promise
// 5

Данный синхронный генератор на 3 и 4 шагах вернет неразрешенные промисы. Однако, асинхронный пользователь for..await..of сможет преобразовать эти шаги в асинхронные.

function* syncGen() {
  yield 1;
  yield 2;
  yield Promise.resolve(3);
  yield Promise.resolve(4);
  yield 5;
}

(async () => {
  for await (const item of syncGen()) {
    console.log(item);
  }
})();

// 1
// 2
// 3
// 4
// 5

Такая же картина будет и с обычными синхронными итераторами.

const syncIterator = {
  i: 0,
  
  [Symbol.iterator]() {
    return this;
  },
  
  next() {
    const done = this.i >= 3;

    if (this.i === 1) {
      return {
        done: false,
        value: Promise.resolve(this.i++),
      };
    }

    return {
      done,
      value: this.i++,
    };
  },
};

for (const item of syncIterator) {
  console.log(item);
}

// 0
// Promise
// 2

Но, применив асинхронный пользователь, второй шаг будет преобразован в асинхронный.

const syncIterator = {
  i: 0,
  
  [Symbol.iterator]() {
    return this;
  },
  
  next() {
    const done = this.i >= 3;

    if (this.i === 1) {
      return {
        done: false,
        value: Promise.resolve(this.i++),
      };
    }

    return {
      done,
      value: this.i++,
    };
  },
};

(async () => {
  for await (const item of syncIterator) {
    console.log(item);
  }
})();

// 0
// 1
// 2

Мои телеграмм-каналы:

English version: https://blog.frontend-almanac.com/iterators