Клиентская оптимизация *

«Связанные списки — это goto структур данных.», — авторство приписывают разным системным программистам.

История из учебника

Все студенты, изучающие computer science, узнают о связанных списках на первом курсе по структурам данных. Их описание звучит привлекательно:

Преимущества (согласно учебникам):

- Вставки и удаления за O(1) в известных позициях

- Динамический размер: увеличиваются и уменьшаются согласно необходимости

- Пространство не тратится впустую: можно распределять ровно столько, сколько нужно

- Гибкость: простота реализации стеков, очередей и других структур

Недостатки (согласно учебникам):

- Поиск за O(n): необходим обход, начиная с головы списка

- Лишняя память: указатели добавляют оверхед

- Невозможность произвольного доступа: нельзя выполнять переходы в произвольные позиции

Вывод из учебника: «Используйте связанные списки, когда требуются частые вставки/удаления и не нужен произвольный доступ».

Вроде бы звучит разумно?

Проверка реальностью

А вот, чего учебники нам не говорят: связанные списки — это почти всегда плохой выбор.

Не потому, что ошибочен анализ «О» большого, в нём всё правильно, а потому, что он неполон. Он забывает про оборудование.

Эта статья - перевод поста в блоге Alex, Baton Corporation Team Lead, вышедшего 20 февраля 2026 г.

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

Вместе с релизом в 1999 году исходного кода Quake был выпущен файл readme.txt, написанный Джоном Кармаком. Особый интерес в нём вызвало одно предложение:

Также для сборки файлов на языке ассемблера требуется Masm. Можно изменить #define и выполнять сборку только с кодом на C, но версии с программным рендерингом при этом потеряют почти половину скорости.

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

«Массив — самая важная структура данных в computer science», — Дональд Кнут (вольное изложение цитаты)

Простейшая структура данных

Массивы настолько просты, что мы иногда воспринимаем их, как нечто само собой разумеющееся. Смежная память, доступ за O(1): что тут ещё оптимизировать?

Всё.

Я работал над конвейером обработки пакетов сетевого коммутатора. Код был простым: считываем пакеты из кольцевого буфера (массива), обрабатываем их и записываем результаты в другой массив. Всё просто, правда?

Но производительность была ужасной. Мы обрабатывали 100 тысяч пакетов в секунду, хотя оборудование должно было справляться с 1 миллионом.

Профилировщик показал нечто странное:

$ perf stat -e cache-misses,instructions ./packet_processor

Performance counter stats:

450,000 cache-misses

1,000,000 instructions

450000 промахов кэша на 1000000 команд? То есть промах происходил раз в 2-3 команды. При простых операциях с массивами это не имело никакого смысла.

Проблема заключалась не в самих массивах, а в том, как мы их использовали.

Решил один мой коллега (не разработчик) заняться пет-проектом: создать платформу с элементами соцсети и встроенным картографическим плагином. И вот приходит этот коллега ко мне с вопросом по части фронтенда: «А как бы мне отрендерить страницы: на сервере или на клиенте?», описывая то решение, которое он уже сделал и которое в целом работает.

Что ж. Меня зовут Андрей, я фронтенд-разработчик в Selectel. В этой статье я расскажу и покажу, какие виды рендеринга веб-страниц существуют и в каком случае лучше использовать тот или иной подход. Разберем все это дело на примерах. Сперва пройдемся по теоретическим основам, а затем — по практике. Если так сложилось, что и вас жизнь привела к подобным фронтендерным запросам, но должного опыта еще нет, добро пожаловать под кат.

Как заставить летать список из 5000+ товаров на странице? Нативный рендер кладёт вкладку, а все базовые оптимизации уже сделаны.

Разбираем послойно: внедрение React Compiler (React 19), виртуализация через TanStack, гибридное кэширование (Redis + unstable_cache) и архитектура работы с анонимными пользователями без лишних запросов к БД. Работа над ошибками, которая ускорила проект в разы.

ВВЕДЕНИЕ

В статье разбирается, почему роль CDTO (Chief Digital Transformation Officer, директор по цифровой трансформации) перестала быть модным западным термином и стала практическим ответом на российские реалии — импортозамещение, рост сложности IT‑ландшафта, усиление регуляторных требований и ускорение конкуренции. Автор показывает типичную картину в компаниях от 300 до 5000 сотрудников: есть множество внедрённых систем (1С, Битрикс24, облака Яндекса и VK, ClickHouse, HR‑ и аналитические решения), но нет единой стратегии, приоритизации и человека, который связывает интересы CEO, CIO, CTO, CFO и бизнеса.

Через конкретные примеры и цифры описывается цена хаотичной цифровизации: проваленные сроки проектов, технический долг, сопротивление сотрудников, неэффективные траты 15–30% IT‑бюджета и потеря доли рынка из‑за медленной трансформации. CDTO в этой логике выступает не «ещё одним айтишником», а владельцем стратегии трансформации, архитектуры, данных, процессов, команды и ROI инвестиций.

Статья даёт структурированный «путеводитель» для собственников и CEO: объясняет, чем CDTO отличается от CIO и CTO, какие функции он берёт на себя ежедневно, какой профиль кандидата искать и по каким критериям его оценивать. Отдельные разделы посвящены первым 100 дням CDTO, пошаговому roadmap трансформации на 36 месяцев, реальным кейсам российских компаний, метрикам и KPI, а также критическим ошибкам, которые чаще всего убивают трансформацию. Завершает материал практический чек‑лист: нужен ли CDTO именно вашей компании, какие есть альтернативы и в каких ситуациях промедление с назначением CDTO превращается в стратегический риск.

Введение

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

Моя основная профессиональная деятельность — машиностроение и она, как и люди в ней работающие, как правило, очень далеки от мира IT. Поэтому когда кто‑то, в моей отросли, говорит про программирование, а особенно, что «занимает программированием», то часто можно услышать это...

Я создал лексер ассемблера ARM64 (ну, точнее, сгенерировал его из моего собственного генератора парсера, но пост не об этом), обрабатывающий код на Dart вдвое быстрее официального сканера. Этого результата я добился при помощи статистических методик надёжного измерения малых различий в производительности. Затем я провёл его бенчмарк на 104000 файлов и обнаружил, что узким местом был не мой лексер, а ввод-вывод. Это история о том, как я случайно узнал, почему pub.dev хранит пакеты в виде файлов tar.gz.

Проблема измерений

Узнав из Главы 2 об иерархии памяти, вы, возможно, захотите оптимизировать свой код. Но есть одна проблема: как понять, что оптимизация на самом деле сработала?

Этот урок дорого мне обошёлся.

Я оптимизировал реализацию хэш-таблицы в загрузчике. Исходя из своего понимания поведения кэша, я переписал хэш-функцию так, чтобы она была «более дружественной к кэшу», и был уверен, что она станет быстрее.

Я запустил код. Мне показалось, что он быстрее. Я закоммитил изменения.

Неделю спустя коллега провёл бенчмарки и выяснил, что моя «оптимизация» замедлила код на 15%. Я оптимизировал не то, но у меня не было данных, чтобы подтвердить мои предположения.

Вывод: никогда не доверяйте своей интуиции, всегда проводите замеры.

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

«Память — это современный диск, диск — это современная лента», — Джим Грей

Проблема ста тактов

В Главе 1 мы говорили о том, что промахи кэша стоят 100-200 тактов, а попадания в кэш — всего 1-4 такта. И это не какая-то мелкая деталь, а самый важный фактор современной производительности.

Ниже я расскажу, почему это так.

Однажды я оптимизировал драйвер устройства для встраиваемой системы на RISC-V. Драйвер должен был обрабатывать пакеты от сетевого интерфейса, но при большой нагрузке мы теряли пакеты. CPU работал с частотой 1 ГГц, а для обработки каждого пакета требовалось около 500 команд. Простая математика:

500 команд ÷ 1 ГГц = 500 наносекунд на пакет

При скорости 500 нс на пакет мы могли бы обрабатывать 2 миллиона пакетов в секунду. Однако мы справлялись всего с 200 тысячами пакетов в секунду, то есть в десять раз меньше, чем ожидалось.

Профилировщик показан следующее:

$ perf stat -e cycles,instructions,cache-misses ./driver_test Performance counter stats:

5,000,000 cycles

500,000 instructions

45,000 cache-misses

Постойте-ка: 500000 команд должны занимать 500000 тактов (при 1 IPC). Но мы видим 5 миллионов тактов. Куда подевались лишние 4,5 миллиона тактов?

Fine-tuned Qwen2.5-0.5B для классификации обращений в поддержку: intent, category, urgency, sentiment, routing — всё в одном JSON. Модель 350 МБ, работает на CPU, стоимость инфраструктуры $10/месяц. Рассказываю как обучал, квантовал и деплоил.

Начнем данную статью с казалось бы простого вопроса: "Кто такие клиенты и зачем их считать?". Ответ на данный вопрос не такой простой и вообще философский! Каждая компания и человек в отдельности ответят на него по-своему.

В телеком компании вам скажут: "Клиент = абонент. Мы считаем их прирост, а также дни, в течение которых они платят нам абонентскую плату.". В небольшой парикмахерской вам, возможно ответят так: "Ну вот кто пришел стричься, тот и клиент. Считаем количество тех, кто постригся за отрезок времени.". Подсчет клиентов может даже пригодиться для оценки компании третьими лицами, здесь также используются свои методологии. И так далее... Думаю, мораль ясна, каждый определяет для себя сам, кто является клиентом и как их считать.

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

Оптимизация кода. Что быстрее: циклы vs стрелочные функции. Простая задача с собеседования. Разбор простых итераций с примерами кода

Часть I: Основы

«В теории теория и практика одинаковы. На практике это не так». — авторство приписывается разными специалистам по computer science

Загадка

Два часа утра. Я смотрю на совершенно нелогичные данные профилирования.

В процессе работы над загрузчиком для SoC RISC-V у нас возникла проблема с производительностью. Загрузчик должен был искать конфигурации устройств в таблице: примерно пятьсот элементов, каждый с 32-битным ID устройства и указателем на данные конфигурации. Всё просто.

Мой коллега реализовал эту систему с помощью хэш-таблицы. «Поиск за O(1), — сказал он уверенно, — лучше уже некуда».

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

Я попробовал использовать очевидную оптимизацию: заменить хэш-таблицу двоичным поиском по отсортированному массиву. Двоичный поиск занимает O(log n), что теоретически хуже, чем O(1). Так написано в учебниках. Мой преподаватель алгоритмов был бы разочарован.

Но в результате загрузчик оказался на 40% быстрее.

Как O(log n) смогло победить O(1)? Что происходит?

Base64 — это схема кодирования двоичных значений в текст, преобразующая произвольные двоичные данные (например, изображения, файлы или любые байтовые последовательности) в безопасную печатную ASCII-строку, состоящую из 64-символьного алфавита (A–Z, a–z, 0–9, +, /). Браузеры применяют эту схему в JavaScript для встраивания двоичных данных непосредственно в код/HTML или для передачи двоичных данных в виде текста.

Недавно в браузерах появились удобные и безопасные функции для обработки Base64: Uint8Array.toBase64() и Uint8Array.fromBase64(). Хоть у них и есть множество параметров, смысл их сводится к кодированию и декодированию.

При кодировании они берут 24 бита из входных данных и разделяют их на четыре сегмента по 6 бит, и каждое 6-битное значение (в интервале от 0 до 63) соотносится с конкретным символом из алфавита Base64: первые 26 символов — это буквы A-Z в верхнем регистре, следующие 26 — a-z в нижнем, затем идут цифры 0-9 и, наконец, символы «+» и «/» в качестве 62-го и 63-го символов. Если длина входных данных не кратна трём байтам, то в качестве заполнителя используется знак «=».

Насколько же быстро могут работать эти функции?

Система ЕРИП (Автоматизированная информационная система «Расчет») функционирует в Беларуси с 2008 года. До недавнего времени для предпринимателей и бизнесменов, принимающих через нее платежи, возврат средств был болезненной темой. Уведомление о платеже поступало мгновенно — а вот вернуть деньги клиенту можно было только через многоэтапную, ручную процедуру, требующую сбора реквизитов, согласований и ожидания. 

Недавно возвраты в ЕРИП перешли в полноценный онлайн-режим — и это не не просто хорошая новость, а реальный рабочий инструмент для бизнеса, в том числе ресторанного, туристического, гостиничного, по аренде недвижимости и др.

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

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

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

Хотелось не просто ускорить метрики, а выстроить полноценную систему, которая бы работала для пользователя как обычное SPA-приложение: быстро, плавно, визуально современно, а главное с уважением к пользователям.

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

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