Типичный программист | 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. Память криптографической библиотеки в эту историю не входит.