Типичный программист

Axiom ускорила сортировку колонок в 2–26 раз с помощью разных алгоритмов Если в колонке всего 15 разных значений, зачем снова и снова сравнивать их при сортировке? В Axiom заменили общую сортировку Go алгоритмами, которые учитывают, как хранятся данные. Для колонок с максимум 15 значениями задали порядок значений и распределили строки по группам за один проход. Это дало ускорение в среднем в 26 раз. Для текста сначала отсортировали словарь уникальных строк, затем сортировали строки таблицы по числовым рангам. Пропуски значений вынесли в отдельную группу, чтобы не проверять их при каждом сравнении. В разборе Axiom показано, как объединить эти алгоритмы интерфейсом Sortable: движок вызывает один метод, а колонка выбирает способ сортировки. Ускорения измерены на блоках из 65 тысяч строк на Apple M4 и относятся к сортировке, а не запросам целиком.

Сортировку ускорили в 26 раз. Общий алгоритм просто знал слишком мало У Axiom разные колонки сортировались одинаково: сравнивали значения по два, каждый раз превращая их во внутренний общий тип. Удобно. Только колонка с уровнями логов уже знала, что разных значений в ней не больше пятнадцати. А сортировка этой подсказкой не пользовалась. Команда дала каждому типу колонки свою реализацию. Для enum сначала упорядочили небольшой словарь, затем разложили строки по счётчикам. Для строк начали сортировать ранги словаря, не сравнивая один и тот же текст снова и снова. На блоках примерно по 65 тысяч строк, на Apple M4, ускорение разных типов составило 2–26 раз. Максимум достался enum. Это не обещание ускорить любую сортировку: выигрыш появился там, где данные уже имели полезную структуру. Её не пришлось придумывать, достаточно было перестать терять при каждом сравнении.

Общая папка для работы Claude Code и Codex Луи-Франсуа Бушар собрал заметки, инструкции-скиллы, скрипты и итоги встреч в Obsidian. Его связка устроена так: Папка хранит исходные материалы и решения ↓ Индекс указывает, где искать данные для задачи ↓ Claude Code планирует работу ↓ Codex выполняет задачи по его вызову В описании этого рабочего процесса Бушар объясняет, зачем даёт агенту сведения для конкретной задачи. Начать предлагает с общей папки, короткого индекса и одного повторно используемого скилла. #ии #инструменты

Сколько памяти стоит пять лет развития 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. Новым экземплярам постепенно добавляли нагрузку, прогревая кеши именно теми товарами, которые они будут обслуживать дальше. #облака

Миллион запросов в секунду мимо общего балансировщика Сто микросекунд задержки выглядят мелочью. Пока один запрос не превращается в сотню параллельных: ответ придёт, когда закончит самый медленный. У Zalando эти обращения ещё и проходили через общий Skipper. При скачках задержки было трудно понять, кто виноват: сервис или чужая инфраструктура. Команда перенесла выбор узла внутрь вызывающего процесса. Пришлось точно повторить прежнее хеш-кольцо, чтобы товары попадали в те же кеши. Переходили постепенно, сохранив обратный путь через Skipper на случай проблем. На пике напрямую пошло больше миллиона запросов в секунду. По данным команды, задержки стабилизировались, а парк Skipper для этих маршрутов сократился с 50+ копий до восьми. Сам Skipper никуда не делся: внешние запросы остались у него. Тут убрали один лишний круг внутри системы, а не переписали весь входной трафик.

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