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

Катастрофа с красно-чёрным деревом

Компилятор тратил 60% времени на поиск символов. Не на парсинг, не на генерацию кода, просто на поиск в таблице символов.

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

«У него O(log n); судя по учебникам, оно идеально подходит для этой цели», — сказал мой коллега.

Но профилировщик показывал иное...

В статье показан практический подход, который помогает сократить время на вёрстку, убрать лишние вопросы и сделать дизайн понятным без дополнительных объяснений. Если вы сталкивались с ситуациями, когда разработчик «не так понял макет», сроки вёрстки дизайна часто переносятся, коммуникация отделов дизайна и разработки хромает — этот материал для вас.

Наверняка вы слышали о новых версиях HTTP — второй и третьей. Что за этими версиями? Зачем они были разработаны? Чем они отличаются от классического HTTP/1.1 и где могут быть полезны? Какие настройки предоставляет веб‑сервер Angie для этих протоколов? Все эти вопросы мы будем разбирать в этой статье.

Начнём с краткой истории развития протокола HTTP.

Миф про O(1)

Говорят, что хэш-таблицы обеспечивают поиск за O(1) — константное время, вне зависимости от размера. В теории они идеальны.

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

Я оптимизировал таблицу символов для компилятора. Таблица символов использовала хэш-таблицу с 1024 бакетами, и у нас было примерно 500 символов. Расчёты выглядели отлично: средний размер бакета = 500/1024 ≈ 0,5, поэтому большинство операций поиска должно выполняться за один запрос.

Но профилировщик рассказал иную историю...

Привет, Хабр!

Менеджеры продаж не всегда вовремя и полно заносят данные о сделках в CRM после звонка. Часть информации может забыться, а часть может быть записана сокращенно.

Прослушивать звонки вручную и восстанавливать детали слишком трудоёмко, а ресурсов на это часто не хватает. Поэтому в этом материале соберём MVP-сервис на Python, который получает событие о завершённом звонке из МТС Exolve, забирает текст разговора, выделяет из него ключевые поля через YandexGPT и записывает результат в Bitrix24. На выходе получится рабочий пайплайн: вебхук, транскрибация, извлечение полей квалификации и обновление существующей сделки в CRM.

За основу возьмём BANT — базовый фреймворк квалификации лида: Budget, Authority, Need, Timing, то есть бюджет, лицо, принимающее решение, потребность и сроки. И расширим его, добавив оценку интереса клиента, фиксацию конкурентов и возражений. Такого набора достаточно, чтобы квалифицировать лид, приоритизировать сделку и сохранить контекст следующего контакта, но не превращать карточку в анкету на десятки полей.

Стек: Python 3.10+, Flask, SQLite, Call Transcribation API МТС Exolve, YandexGPT API, Bitrix24 REST API.

Внутренний трекер задач — Яндекс Трекер — важная часть Яндекса. В нём хранятся почти все планы: от целей отделов, до тикетов поддержки. RPS на фронтенд измеряется сотнями, а количество хитов в месяц — десятками миллионов. При таком масштабе даже небольшие задержки могут становиться критичными, поэтому мы задались целью ускорить Трекер. Спойлер: всё получилось не совсем так, как мы ожидали. Но обо всём по порядку. 

Для измерения скорости сервисов в Яндексе используется метрика Velocity Index — это агрегация метрик Web Vitals (FCP, LCP, TBT, INP, CLS). Итоговое значение получается в диапазоне от 0 до 100 баллов. Хорошим результатом считается индекс больше 85.

Мы поставили себе амбициозную цель: увеличить Velocity Index до 85, а заодно подлечить очевидные «узкие места» в скорости и ускорить всё, до чего сможем дотянуться.

Но до заветных 85 баллов мы так и не добрались.

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

В помощь начинающему, продолжающему и заканчивающему автору.

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

В этом гайде я покажу, как собрать двунаправленный бесконечный скролл с нуля. Здесь React и @tanstack/react-virtual, но сама техника — просто математика над scroll offset. Работает так же в Vue, Svelte или на ванильном JS.

Демо | Исходный код

Привет, Хабр! Меня зовут Виктория Мохирева, я консультант SAP MM. Сегодня расскажу о том, как мы с командой решили колоссальную задачу инвентаризации — пересортицу товаров — с помощью интеграции SAP с большой языковой моделью (ИИ).

Вот как бывает в обыденности магазина: пришёл товар, на учете кружка, а на полке по факту тарелка. Начинается танец с бубном из таблиц, сверка номенклатур и постоянные акты. Чтобы автоматизировать подбор правильных групп для пересортицы, мы написали инструмент, который позволяет общаться с ИИ напрямую из SAP GUI. Решение получилось достаточно компактным и элегантным. А под капотом у нас — архитектура, ключевые куски кода и логика, которые помогли нам превратить «регулярный ручной труд» в интеллектуальный диалог с машиной, и теперь у нас не разрозненная масса товаров, а сформированные по определенным параметрам логичные группы.

«Простота — требование, необходимое для обеспечения надёжности», — Эдсгер Дейкстра

Невидимая структура данных

В каждой программе используется стек — стек вызовов. Каждый вызов функции записывает в стек кадр, каждый возврат извлекает его. Он настолько фундаментален, что мы редко о нём задумываемся.

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

Однажды я отлаживал вылет прошивки во встраиваемой системе RISC-V. У системы был планировщик задач, использующий очередь для управления ожидающими задачами. При большой нагрузке система вылетала с переполнением стека.

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

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

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

Краткий итог нашего изучения рынка и создания собственного бота (почему это так - читайте ниже):

Промпт-бот (500 ₽ фриланс + 50 000 ₽/месяц API):
Используйте, если нужно простое FAQ-покрытие, вся база знаний умещается в короткий промпт, нет регуляторного риска и вы понимаете, что принимаете риск галлюцинаций и нарушений ограничений. Хорошо для демонстрации возможностей. Не подходит для финансовых услуг, медицины, юридических вопросов или любой области, где неверный ответ бота имеет последствия.

SaaS-платформа (3 000–100 000+ ₽/месяц):
Используйте, если главным образом нужно FAQ-отклонение и маршрутизация обращений, каталог продуктов стабилен и прост, есть команда поддержки, которая хочет единый inbox, и вы хотите запуститься за несколько дней. Aimylogic и BotHelp достаточно хороши для своего предназначения. Российские платформы решают вопрос 152-ФЗ лучше западных аналогов.

Open-source-фреймворк (Rasa/Botpress, $0 ПО + инфра + программисты):
Rasa даёт полный контроль с локальным NLU и управлением диалогом. Требует Python-инженера и реальных обучающих данных. Корпоративное лицензирование начинается от $35 000/год. Подходит для ML-тяжёлых сценариев, где нужен полный контроль. Требует постоянной поддержки, которую SaaS берёт на себя.

Кастомный гибрид (инвестиции в код + ~5 000 ₽/месяц API):
Используйте, если нужны управляемые многошаговые квалификационные потоки, данные о продуктах синхронизированы с существующей системой, есть требования к локализации данных или соответствию 152-ФЗ, нестандартная интеграция с каналами или предсказуемость затрат на долгий срок. Не проект выходного дня, но при масштабировании экономика очевидна. По данным рынка, полная разработка «под ключ» в России стоит 70 000–1 000 000 ₽ единоразово (медиана 227 000 ₽ по исследованию Aimylogic).

Привет, Хабр! Меня зовут Sonic. Я собрал SonicBoost — бесплатную утилиту с открытым кодом, которая вытаскивает из Windows 10/11 максимум FPS. 28 твиков реестра, управление службами, блокировка телеметрии, оптимизация сети — всё в одном EXE на 65 МБ. Под капотом .NET 8, WPF UI с Mica-эффектом и ни одного подозрительного скрипта — весь код на GitHub.

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

Зачем вообще нужен ещё один твикер?

Каждый геймер знает ощущение: собрал машину за 200к, а в Valorant на ALT+TAB — фриз на 3 секунды. FPS скачет, пинг гуляет, микрофризы в самый неподходящий момент.

Проблема не в железе. Проблема в том, что Windows — это корпоративная ОС, а не игровая. По умолчанию там крутятся:

«Связанные списки — это 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 превращается в стратегический риск.

Введение

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