Типичный программист | IT, программирование, разработка, ИИ

Завтра иду на GoCloud Tech 2026

Кому интересно узнать какие-нибудь подробности с мероприятия? Могу потом рассказать отдельно!

И, конечно, можем увидеться там, если вы тоже идёте 😉

Axiom ускорила сортировку колонок в 2–26 раз с помощью разных алгоритмов

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

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

В разборе Axiom показано, как объединить эти алгоритмы интерфейсом Sortable: движок вызывает один метод, а колонка выбирает способ сортировки. Ускорения измерены на блоках из 65 тысяч строк на Apple M4 и относятся к сортировке, а не запросам целиком.

Сортировку ускорили в 26 раз. Общий алгоритм просто знал слишком мало

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

Команда дала каждому типу колонки свою реализацию. Для enum сначала упорядочили небольшой словарь, затем разложили строки по счётчикам. Для строк начали сортировать ранги словаря, не сравнивая один и тот же текст снова и снова.

На блоках примерно по 65 тысяч строк, на Apple M4, ускорение разных типов составило 2–26 раз. Максимум достался enum. Это не обещание ускорить любую сортировку: выигрыш появился там, где данные уже имели полезную структуру. Её не пришлось придумывать, достаточно было перестать терять при каждом сравнении.

Сколько памяти стоит пять лет развития libcurl

Новые функции добавляются по одной, и расход памяти может расти так же незаметно. Дэниел Стенберг сравнил libcurl с версией пятилетней давности: при загрузке файла на 512 МБ по HTTP пиковая память выросла на 1,6%, а число выделений памяти на 11%.

Чтобы ловить случайный рост раньше, в тесты curl добавили проверку размеров 15 структур. У каждой есть верхний предел: превысили его, тест падает. Ради новой функции лимит можно пересмотреть, но увеличение уже придётся заметить.

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

#opensource

Пять лет новых функций. Сколько памяти теперь ест libcurl?

Обычно от такого сравнения ждёшь грустного графика. Дэниел Стенберг, автор curl, сопоставил libcurl 7.75.0 и 8.19.0-DEV и получил смешанную картину: структура одного соединения уменьшилась с 1472 до 912 байт, а две другие выросли.

Для десяти передач и двадцати открытых соединений сумма этих трёх структур оказалась на 10 000 байт меньше. Но при скачивании одного файла на 512 МБ пик памяти вырос на 1,6%, а число аллокаций увеличилось с 96 до 107. Один красивый показатель тут легко спрятал бы второй.

В тестах curl теперь есть проверка размеров пятнадцати важных структур. Превысил лимит — сборка упала, дальше приходится объяснять рост. Замеры Стенберга сделаны на Linux с HTTP без TLS. Память криптографической библиотеки в эту историю не входит.

Сжатие временных рядов в Axiom: меньше места на диске, больше работы процессору

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

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

На данных Axiom хранилище обычно занимает 30–50% от размера Gorilla. Но оптимизированная Gorilla примерно в 15 раз эффективнее по CPU, то есть затратам процессора на кеш. Память кеша чаще составляет 70–100% от Gorilla; все цифры зависят от нагрузки.

#облака

Gran Turismo 4 переехала в Chrome — с гонками, звуком и сохранениями

В PS2 Web Recomp старые игры запускают прямо во вкладке. Gran Turismo 4 проходит меню и гонки, играет музыку и сохраняет прогресс в браузере. По замерам автора, PAL-версия держит 50 FPS в Chrome на встроенной графике ноутбука при удвоенном разрешении PS2.

Машинный код игры заранее переводят в C++, затем собирают в WebAssembly. Графику рисует WebGPU, а окружение воспроизводит нужные части системы и железа PS2. После Gran Turismo автор запустил God of War II: вторая игра помогла найти ошибки, которых первая не замечала.

📎 В репозитории проекта есть код, скрипты сборки и подробности оптимизации. Готового каталога игр здесь нет: понадобится свой образ диска, который скрипты превратят в локальную веб-страницу.

Миллион запросов в секунду напрямую: разбор клиентской балансировки Zalando

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

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

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

#облака

Как метрики помогли найти ошибку в ИИ-оценщике размера видео

Cliparr обещал один размер видео, а после конвертации получался другой: в 16 замерах файлы оказались на 30–83% больше прогноза. ИИ написал формулу, которая уменьшала ожидаемый размер пропорционально высоте кадра, хотя при заданном битрейте расчёт должен опираться на длительность.

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

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

#ии #веб

Замена Redis на MySQL в Shopify: устройство резервов и поиск дефицита соединений

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

Команда завела строки для отдельных единиц, ограничив запас 1000 строк на товар и место хранения. SKIP LOCKED позволяет при резервировании пропускать заблокированные строки и выбирать свободные.

Запросы ускорились, но соединений всё равно не хватало. Метки в SQL-запросах и замеры на прокси показали: другие части оформления заказа удерживали соединения слишком долго. В разборе миграции Shopify есть эта диагностика, подбор ключей и уровня изоляции, а также проверка двух систем в параллельной работе.

#веб