Профилирование

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

При работе с десятками тысяч объектов нагрузка распределяется между несколькими компонентами:

React-интерфейсом;
Redux-хранилищем;
системой рендеринга Deck.gl;
WebGL-контекстом;
обработкой геоданных;
браузерным движком JavaScript.

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

Основные виды производительности

В контексте Kepler.gl обычно анализируются несколько категорий производительности.

Производительность загрузки данных

Характеризует время между началом импорта и появлением слоя на карте.

На скорость загрузки влияют:

объём входного файла;
формат данных;
количество столбцов;
наличие геометрий высокой детализации;
преобразования данных перед отображением.

Пример проблемного сценария:

dispatch(
  addDataToMap({
    datasets: {
      info: {
        label: 'Large Dataset'
      },
      data: hugeGeoJson
    }
  })
);

Если hugeGeoJson содержит сотни тысяч объектов, загрузка может занимать несколько секунд.

Производительность отрисовки

Связана с количеством объектов, которые должны быть визуализированы через Deck.gl.

Критические факторы:

число вершин полигонов;
количество отображаемых слоёв;
активные эффекты освещения;
прозрачность;
анимация.

Например:

{
  type: 'geojson',
  config: {
    dataId: 'cities',
    isVisible: true
  }
}

Если слой содержит сложные полигоны административных границ, нагрузка на GPU возрастает многократно.

Производительность взаимодействия

Оценивает скорость отклика интерфейса.

Проверяются:

масштабирование карты;
перемещение камеры;
переключение слоёв;
изменение фильтров;
обновление настроек визуализации.

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

Производительность использования памяти

Важна при длительной работе приложения.

Признаки проблем:

постепенный рост потребления памяти;
отсутствие освобождения ресурсов;
утечки WebGL-объектов;
накопление неиспользуемых данных в Redux.

Инструменты профилирования

Chrome DevTools

Наиболее распространённый инструмент анализа производительности.

Основные вкладки:

Performance;
Memory;
Rendering;
Network.

Открытие:

F12 → Performance

Позволяет записывать полную временную диаграмму выполнения приложения.

React DevTools Profiler

Используется для анализа React-компонентов.

Особенно полезен при интеграции Kepler.gl в собственные приложения.

Установка:

Chrome Web Store → React Developer Tools

После установки появляется вкладка:

Profiler

Она показывает:

количество рендеров;
длительность рендера;
цепочку обновлений компонентов.

Redux DevTools

Поскольку Kepler.gl активно использует Redux, значительная часть производительности зависит от действий и изменений состояния.

Инструмент позволяет отслеживать:

{
  type: '@@kepler.gl/LAYER_CONFIG_CHANGE'
}

или

{
  type: '@@kepler.gl/SET_FILTER'
}

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

WebGL Inspector

При работе с тяжёлыми слоями полезен анализ WebGL-вызовов.

Проверяются:

количество draw call;
объём видеопамяти;
частота создания буферов;
пересоздание шейдеров.

Профилирование загрузки данных

Измерение времени импорта

Простейший способ анализа — использование API производительности браузера.

performance.mark('load-start');

dispatch(addDataToMap(config));

performance.mark('load-end');

performance.measure(
  'dataset-load',
  'load-start',
  'load-end'
);

Получение результата:

console.log(
  performance.getEntriesByName('dataset-load')
);

Анализ времени парсинга

При загрузке GeoJSON часто именно парсинг становится самым затратным этапом.

Пример:

const data = JSON.parse(rawJson);

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

Профилирование позволяет определить:

время чтения файла;
время десериализации;
время построения внутренних структур.

Использование Performance Timeline

performance.mark('parse-start');

const dataset = JSON.parse(content);

performance.mark('parse-end');

performance.measure(
  'parsing',
  'parse-start',
  'parse-end'
);

Полученные данные отображаются в Chrome DevTools.

Анализ React-компонентов

Поиск лишних перерисовок

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

Пример:

function MapContainer(props) {
  return <KeplerGl id="map" />;
}

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

Использование React.memo

Оптимизация:

const MapContainer = React.memo(function MapContainer() {
  return <KeplerGl id="map" />;
});

После применения профайлер показывает снижение количества рендеров.

Анализ Commit Time

React Profiler предоставляет показатель:

Commit Duration

Он показывает время, затраченное на применение изменений к DOM.

Большие значения обычно свидетельствуют о:

сложных вычислениях;
избыточных обновлениях состояния;
тяжёлых дочерних компонентах.

Профилирование Redux

Анализ количества действий

Иногда одно действие запускает целый каскад обновлений.

Например:

dispatch(updateVisData(data));

может привести к:

UPDATE_VIS_DATA
LAYER_CONFIG_CHANGE
VIS_STATE_UPDATE
TRIGGER_RENDER

Каждое обновление увеличивает нагрузку.

Измерение времени обработки действий

Middleware позволяет регистрировать длительность операций.

const profiler = store => next => action => {
  const start = performance.now();

  const result = next(action);

  const end = performance.now();

  console.log(
    action.type,
    end - start
  );

  return result;
};

Такой подход помогает обнаруживать дорогостоящие операции.

Профилирование Deck.gl

Роль Deck.gl в производительности

Kepler.gl строится поверх Deck.gl.

Основная нагрузка возникает именно здесь:

Redux
   ↓
Kepler.gl
   ↓
Deck.gl
   ↓
WebGL

Поэтому анализ Deck.gl имеет критическое значение.

Использование логирования Deck.gl

Включение детального вывода:

import {log} from '@deck.gl/core';

log.enable();

Логи содержат информацию о:

пересоздании слоёв;
обновлении атрибутов;
изменениях буферов.

Отслеживание обновлений слоя

new ScatterplotLayer({
  id: 'points',
  data,
  updateTriggers: {
    getRadius: radius
  }
});

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

Профилирование позволяет обнаружить подобные ситуации.

Анализ частоты кадров

FPS как индикатор производительности

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

Целевые показатели:

FPS	Состояние
60	Отлично
45–60	Хорошо
30–45	Допустимо
Менее 30	Проблема

Мониторинг FPS

Пример использования библиотеки stats.js:

import Stats from 'stats.js';

const stats = new Stats();

document.body.appendChild(stats.dom);

function animate() {
  stats.begin();

  requestAnimationFrame(animate);

  stats.end();
}

animate();

Позволяет наблюдать производительность в реальном времени.

Профилирование памяти

Анализ Heap Snapshot

Вкладка Memory в Chrome позволяет создавать снимки памяти.

Этапы анализа:

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

Проверяется наличие объектов, которые должны были быть удалены.

Поиск утечек данных

Пример потенциальной утечки:

const cache = [];

function saveData(dataset) {
  cache.push(dataset);
}

Если данные никогда не удаляются, потребление памяти будет постоянно расти.

Утечки обработчиков событий

Распространённая ошибка:

window.addEventListener(
  'resize',
  onResize
);

Без удаления:

window.removeEventListener(
  'resize',
  onResize
);

Обработчики продолжают существовать после уничтожения компонентов.

Профилирование геопространственных данных

Анализ размера GeoJSON

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

Пример:

console.log(
  geojson.features.length
);

Дополнительно анализируется количество координат.

let vertices = 0;

geojson.features.forEach(feature => {
  vertices += feature.geometry.coordinates.length;
});

Чем больше вершин, тем выше нагрузка на GPU.

Упрощение геометрии

Высокодетализированные полигоны часто становятся причиной снижения производительности.

До оптимизации:

1 000 000 вершин

После применения алгоритмов упрощения:

50 000 вершин

Время рендеринга может сократиться в десятки раз.

Кластеризация точек

Большие наборы точек выгодно агрегировать.

Вместо:

500 000 объектов

можно отображать:

5 000 кластеров

Нагрузка на видеокарту значительно снижается.

Профилирование фильтров

Стоимость вычислений фильтрации

Каждое изменение фильтра инициирует перерасчёт данных.

Пример:

dispatch(
  setFilter({
    value: [100, 500]
  })
);

При больших объёмах данных операция может занимать заметное время.

Измерение задержек

const start = performance.now();

dispatch(updateFilter(filter));

const end = performance.now();

console.log(end - start);

Результаты позволяют определить предельные объёмы данных для выбранного типа фильтра.

Профилирование анимаций

Проверка плавности воспроизведения

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

Основные источники нагрузки:

обновление таймлайна;
пересчёт атрибутов слоёв;
обновление WebGL-буферов.

Анализ кадров

В Chrome Performance можно определить:

длительность кадра;
блокировки главного потока;
длительные задачи JavaScript.

Критическим считается кадр длительностью более:

16.6 мс

поскольку это препятствует достижению 60 FPS.

Поиск узких мест

CPU-bound сценарии

Признаки:

высокий процент использования процессора;
длительные JavaScript-задачи;
низкая загрузка GPU.

Типичные причины:

сложные преобразования данных;
агрегации;
вычисление статистики на клиенте.

GPU-bound сценарии

Признаки:

медленная отрисовка;
снижение FPS при масштабировании;
большое число полигонов.

Причины:

сложные шейдеры;
чрезмерное количество вершин;
множество одновременно отображаемых слоёв.

Memory-bound сценарии

Признаки:

рост потребления памяти;
частые сборки мусора;
зависания интерфейса.

Причины:

хранение избыточных данных;
утечки объектов;
отсутствие очистки ресурсов.

Практический процесс профилирования

Шаг 1. Фиксация проблемы

Определяется конкретный симптом:

Медленная загрузка
Низкий FPS
Зависания интерфейса
Рост памяти

Шаг 2. Запись профиля

Используется Chrome Performance.

Запись должна охватывать полный сценарий:

Загрузка данных
Масштабирование
Перемещение карты
Фильтрация

Шаг 3. Поиск горячих участков

Анализируются:

Long Tasks;
JavaScript Call Tree;
GPU Activity;
Memory Allocation.

Шаг 4. Внесение оптимизации

Возможные меры:

упрощение геометрии;
кластеризация;
мемоизация компонентов;
сокращение количества слоёв;
оптимизация фильтров.

Шаг 5. Повторное измерение

После каждого изменения выполняется новое профилирование.

Сравниваются показатели:

Метрика	До	После
Время загрузки	4.8 с	1.2 с
FPS	24	58
Память	1.3 ГБ	420 МБ
Время фильтрации	650 мс	70 мс

Только повторные измерения позволяют объективно оценить эффективность оптимизации и подтвердить улучшение производительности приложения на базе Kepler.gl.