Незаметный рефакторинг, сэкономивший
90% памяти в TanStack Table V9

Введение

TanStack Table V9 разрабатывался несколько лет, принеся переписанную с нуля систему управления состоянием, более лёгкую плагинную архитектуру и модель выполнения «плати за то, чем пользуешься». Но один из самых значительных выигрышей в производительности пришёл из неожиданного места: рефакторинга, настолько незаметного, что большинство разработчиков пролистали бы его в PR.

Суть изменения: вместо того чтобы определять методы прямо на каждом объекте Row, Column, Cell и Header, TanStack Table V9 хранит их на разделяемых прототипах и создаёт экземпляры через Object.create(proto). Результат — до 90% снижения расхода памяти для больших таблиц: с 272 MB до 27 MB для 100 000 строк с постраничной навигацией.

Эта статья — глубокий разбор того, как работает этот рефакторинг, паттерны кода «до» и «после», бенчмарки и почему эту технику можно применить в любом JavaScript-проекте, создающем множество однотипных объектов.

Проблема: объектные литералы создают накладные расходы на каждый экземпляр

В TanStack Table V8 каждый Row, Column, Cell и Header был простым объектным литералом. Каждый нёс не только свойства с данными (вроде id, index, original), но и все методы — getValue, getUniqueValues, renderValue, getLeafRows, getParentRow, getAllCells и ещё с десяток методов от плагинов.

const row = {
  // данные
  id,
  index: rowIndex,
  original,
  depth,
  parentId,
  _valuesCache: {},
  _uniqueValuesCache: {},

  // методы — дублируются на КАЖДОЙ строке
  getValue: (columnId) => {
    // ...реализация...
  },
  getUniqueValues: (columnId) => {
    // ...реализация...
  },
  renderValue: (columnId) =>
    row.getValue(columnId) ?? table.options.renderFallbackValue,
  getLeafRows: () => flattenBy(row.subRows, (d) => d.subRows),
  getParentRow: () =>
    row.parentId ? table.getRow(row.parentId, true) : undefined,
  getAllCells: memo(/* ... */),
  _getAllCellsByColumnId: memo(/* ... */),
  // и ещё с дюжину методов от плагинов...
}

При 100 000 строк и 10+ методах каждая — это более миллиона объектов-функций, созданных для одних только методов. И каждый — независимое замыкание со своей цепочкой областей видимости. V8 не дедуплицирует их, потому что каждый объектный литерал создаёт свежие экземпляры функций.

Решение: разделяемые прототипы с Object.create

Исправление элегантно и концептуально просто: создайте один объект-прототип для каждого типа (Row, Column, Cell, Header) со всеми методами, затем используйте Object.create(prototype) для создания экземпляров, наследующих методы от общего прототипа. Свойства с данными устанавливаются через Object.assign на каждый экземпляр.

// Разделяемый прототип — создаётся один раз
const rowPrototype = {
  getValue(columnId) {
    // ...this работает — ссылается на экземпляр...
  },
  getUniqueValues(columnId) {
    // ...реализация...
  },
  renderValue(columnId) {
    return this.getValue(columnId) ??
      this.table.options.renderFallbackValue;
  },
  getLeafRows() {
    return flattenBy(this.subRows, (d) => d.subRows);
  },
  getParentRow() {
    return this.parentId
      ? this.table.getRow(this.parentId, true)
      : undefined;
  },
  getAllCells: memo(/* ... */),
  _getAllCellsByColumnId: memo(/* ... */),
};

// Создание экземпляра — одна строка, минимум памяти
function createRow(data) {
  const row = Object.create(rowPrototype);
  Object.assign(row, {
    id: data.id,
    index: data.rowIndex,
    original: data.original,
    depth: data.depth,
    parentId: data.parentId,
    _valuesCache: {},
    _uniqueValuesCache: {},
  });
  return row;
}

Теперь каждая строка хранит только свои поля с данными (~6 свойств). 10+ методов живут на общем rowPrototype — по одной копии каждого, независимо от количества строк. Экономия накапливается на типах Row, Column, Cell и Header, у каждого из которых был свой набор методов.

Результаты бенчмарков

Цифры говорят сами за себя. TanStack опубликовал замеры retained JS heap по четырём сценариям: постраничная разбивка, виртуализация строк, виртуализация колонок и комбинированный «kitchen sink».

Паттерн стабилен: чем больше ячеек обрабатывает TanStack Table, тем значительнее экономия. Для маленьких таблиц (80 ячеек) разница незаметна (1-2%). Но в масштабе — а именно там память критична — улучшение трансформирующее.

Почему не использовать классы JavaScript?

Естественный вопрос: если методы на прототипе так хороши, почему не взять ES6-классы? Ведь методы классов тоже живут на прототипе.

Проблема в том, что TanStack Table передаёт методы по ссылке в мемоизированные функции, обработчики событий и плагины. При этом контекст this теряется. Стандартное решение — .bind(this), стрелочные функции или геттеры, возвращающие привязанные методы — создаёт новый экземпляр функции на каждую строку, сводя на нет всю экономию:

class Row {
  constructor(data) {
    this.id = data.id;
    this.index = data.rowIndex;
    // ...
    // Если привязать методы здесь — они снова на каждый экземпляр:
    this.getValue = this.getValue.bind(this);  // новая функция на строку!
    this.renderValue = this.renderValue.bind(this);  // то же самое!
  }

  getValue(columnId) { /* ... */ }
  renderValue(columnId) { /* ... */ }
}

С Object.create вы получаете лучшее из двух миров: разделение методов на уровне прототипа, отсутствие накладных расходов на привязку и динамическое разрешение this через цепочку прототипов в момент вызова. Методы на прототипе используют this так же, как методы классов — но им никогда не нужна привязка, потому что вызывающий код получает экземпляр напрямую.

Как это работает: механика цепочки прототипов JavaScript

Для разработчиков, не знакомых с механизмом, — краткое пояснение того, что делает Object.create:

const proto = {
  greet() { return `Привет, я ${this.name}`; }
};

const alice = Object.create(proto);
alice.name = 'Алиса';
const bob = Object.create(proto);
bob.name = 'Боб';

console.log(alice.greet()); // "Привет, я Алиса"
console.log(bob.greet());   // "Привет, я Боб"

// Обе используют ОДНУ функцию greet():
console.log(alice.greet === bob.greet); // true

// Но у каждой своё 'name':
console.log(alice.hasOwnProperty('name')); // true
console.log(alice.hasOwnProperty('greet')); // false — унаследовано

Ключевой момент: alice.greet === bob.greet даёт true, потому что greet живёт на proto, а не на каждом экземпляре. Метод хранится в памяти один раз, но оба объекта могут вызывать его со своим собственным this.

Почему не сделали это в Table V8?

PR с прототипным разделением был создан несколько лет назад Майклом Лейбманом. Его так и не приняли из-за одной критической проблемы: перечислимые методы прототипа.

В JavaScript методы, определённые на прототипе, по умолчанию имеют флаг enumerable: true. Это значит, что они появляются в Object.keys(), циклах for...in и spread-операциях:

const row = Object.create(rowPrototype);
Object.assign(row, { id: '1', index: 0 });

// Код V8 может делать так и получать неожиданные методы:
console.log(Object.keys(row));
// ['id', 'index'] — ОК, только собственные свойства

// Но spread и for...in перечисляют методы прототипа:
console.log({ ...row });
// { id: '1', index: 0, getValue: fn, renderValue: fn, ... } — ПЛОХО!

Исправление всех потребителей на использование hasOwnProperty или Object.keys (который перечисляет только собственные свойства) было обратно несовместимым изменением. V8 не могла его принять. V9, с её мажорным номером и другими ломающими изменениями (новая система состояния, плагинная архитектура), стала подходящим моментом.

Как применить этот паттерн в своих проектах

Красота этой техники — в её универсальности. Любая библиотека или приложение, создающее множество однотипных объектов с одинаковым набором методов, может выиграть. Вот когда это имеет смысл:

• Вы создаёте тысячи однотипных объектов — строки таблицы, узлы дерева, сущности в игровом цикле, ячейки.
• У каждого объекта 5+ методов — чем больше методов, тем значительнее экономия.
• Вы контролируете создание объектов — у вас есть фабричная функция или конструктор.
• Вы не используете spread/for...in на этих объектах — или можете обновить потребителей на Object.keys.

Универсальный паттерн реализации:

// 1. Определяем разделяемый прототип
const entityPrototype = {
  update(deltaTime) {
    this.x += this.vx * deltaTime;
    this.y += this.vy * deltaTime;
  },
  getPosition() {
    return { x: this.x, y: this.y };
  },
  isOutOfBounds(width, height) {
    return this.x < 0 || this.x > width ||
           this.y < 0 || this.y > height;
  },
};

// 2. Фабричная функция через Object.create + Object.assign
export function createEntity({ x, y, vx, vy, type }) {
  const entity = Object.create(entityPrototype);
  Object.assign(entity, { x, y, vx, vy, type });
  return entity;
}

В этом примере с системой частиц из 10 000 сущностей каждая хранит только 5 числовых свойств. 3 метода разделяются. Без прототипного разделения каждая частица несла бы свои копии update, getPosition и isOutOfBounds — 30 000 объектов-функций против 3.

Компромиссы и ограничения

Ни один паттерн не универсален. Вот когда прототипное разделение не является правильным выбором:

• Малое количество объектов — для десятков или сотен экземпляров разница в памяти незаметна, а усложнение кода не оправдано.
• Уникальные объекты — если каждому объекту нужен свой набор методов, разделять нечего.
• Активное использование spread/for...in — если кодовая база heavily relies на перечисление всех свойств, цена ломающего изменения может быть высока.
• Микрооптимизации на хот-пате — обращение к цепочке прототипов чуть медленнее прямого доступа к свойству. JIT V8 может агрессивнее девиртуализировать мономорфные классы. На практике это редко имеет значение, но стоит профилировать.

Часто задаваемые вопросы

Заключение

История с памятью в TanStack Table V9 — напоминание о том, что самые эффективные оптимизации не всегда самые сложные. Глубокое понимание прототипной системы JavaScript — языковой возможности, которую многие разработчики используют ежедневно не задумываясь — открыло 90% сокращение памяти, от которого выигрывает каждый пользователь библиотеки.

Этот паттерн переносим. Строите ли вы дата-грид, виртуализированный список, игровой движок или любую систему, создающую множество однотипных объектов — Object.create с разделяемыми прототипами — это простое и эффективное улучшение, почти ничего не стоящее при внедрении в мажорном релизе.

Если вы создаёте производительные JavaScript-приложения и нуждаетесь в экспертной помощи, свяжитесь со мной. Я специализируюсь на оптимизации React и Node.js с 20-летним опытом создания production-приложений, работающих в масштабе.