Саймон Уиллисон с Claude ускорил разбор чисел в SQLite с 67 до 19 нс

Выгрузили платежи в CSV, загрузили в SQLite, а в колонке с суммами лежит «-$1,234.56». Для человека это число, для базы — строка, которую нужно разобрать перед сложением и сортировкой. Саймон Уиллисон решил проверить, насколько сложно добавить для этого функцию parse_number(), и поручил Claude сравнить реализации на C и Rust.

Получился небольшой, но полезный инженерный эксперимент. Сначала Rust выиграл по скорости, а C — по размеру расширения. Затем Уиллисон попросил заменить функцию разбора числа в C, и расклад поменялся: на смешанных данных время обработки строки снизилось с 67 до 19 наносекунд. Практический смысл здесь — в том, как один конкретный участок кода меняет результат сравнения языков.

Одна SQL-функция вместо очистки в каждом запросе

Задача у parse_number() простая: убрать из строки запятые, знаки валют и процента, учесть начальный минус и вернуть числовое значение. Если разобрать строку нельзя, функция должна вернуть NULL. Такое поведение позволяет вынести повторяющуюся очистку в расширение SQLite и затем использовать результат в вычислениях.

Например, «-$1,234.56» после удаления доллара и разделителя тысяч превращается в -1234.56. Дальше это значение можно складывать с другими платежами или сортировать как число. Разработчику не приходится заново собирать цепочку строковых замен в каждом запросе.

С процентами правила стоит определить отдельно. В исходном запросе Уиллисон предложил удалять знак процента. Но для конкретного продукта нужно решить, означает ли «12.5%» число 12.5 или долю 0.125. От этого зависит правильность последующих вычислений. Сам по себе быстрый разбор строки такого решения за команду не принимает.

Почему Rust сначала оказался быстрее

Claude подготовил варианты расширения на C и с двумя библиотеками Rust: rusqlite и sqlite-loadable-rs. По данным Уиллисона, собранное расширение на C занимало 14 КБ. Варианты на Rust — 321 и 298 КБ соответственно. Для небольшой встраиваемой утилиты такая разница может иметь значение.

Однако первая версия на C проигрывала по скорости. На смешанных данных её дополнительная стоимость обработки составляла 67 нс на строку, тогда как варианты на Rust показывали 46 и 41 нс. Уиллисон связал разницу с разбором чисел: использованный в Rust механизм работал быстрее стандартной функции C strtod.

Следующий запрос к Claude был уже точечным: написать собственную функцию разбора десятичного числа на C, способную догнать или обойти Rust. После этой замены вариант на C показал 19 нс на смешанных данных, 16 нс на целых числах и 18 нс на десятичных дробях.

Для сравнения: на десятичных дробях исходная версия C требовала 106 нс, а варианты Rust — 55 и 47 нс. Все приведённые замеры относятся к эксперименту на двух миллионах строк. Речь идёт о дополнительной стоимости обработки строки, поэтому переносить эти цифры на время выполнения целого SQL-запроса напрямую нельзя.

Что проверить перед использованием

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

При этом ускорение ещё не доказывает, что самописный парсер полностью заменяет стандартный. Перед использованием стоит проверить допустимые форматы, очень большие значения, округление, пробелы и строки с мусором. Если продукт принимает суммы из разных стран, отдельно понадобятся правила для десятичной запятой и разделителей тысяч. Это вопросы к проверке реализации, а не установленные недостатки опубликованного кода.

Уиллисон также попросил Claude оформить исследование и выложил результат в репозитории simonw/research. Для разработчика это отправная точка: повторить замеры на своей выгрузке, проверить корректность и только после этого выбирать реализацию. Claude в этой истории помог быстро пройти путь от идеи до нескольких измеренных вариантов; оценивать их пригодность всё равно приходится по требованиям конкретной системы.