Снова появился повод вспомнить "бинарные логи" и любителей заняться юниксвэем.

В последнее время, к нам переходит много пользователей Debian. Это очень здорово, т.к. свежим глазом видится много того, что мы или не замечаем, или к чему давно привыкли и забыли. Недавно очередной бывший пользователь Debian недоуменно спросил - почему bash completion при установке пакетов происходит так медленно? Мы как то и не думали об этом, ну тормозит, и ладно, но после претензии от новичка наши участники решили разобраться, в чем же дело.

Несмотря на устоявшееся мнение о превосходных элитных программистах Red Hat, сформировавшееся вследствии практики компании нанимать топовых разработчиков в интересующих ее сегментах, основную массу инженеров Red Hat составляют обычные простые ребята, такие же, как мы. Они также, как мы, зашиваются с дедлайнами, порой любят набыдлокодить, чтоб быстрее побежать дальше, или даже просто не знают всех деталей и проблематики решаемых ими задач. Как результат, ошибок и неоптимального кода они делают не меньше нашего (но уж, конечно, никак не больше). К счастью, наше коммьюнити всегда отличалось доброжелательностью и взаимопомощью, и если мы что-нибудь нехорошее находим, то вместо излияния потоков взаимных оскорблений и зашкаливающей ненависти, как это принято в некоторых других сообществах, мы помогаем друг другу.

Наш коллега, Igor Gnatenko, изучив вопрос с тормозами bash completion, выяснил, что дело в том, что для поиска варианта для дополнения команды используется понятный и "читаемый глазами" текстовый файл, вместо эффективного бинарного. Ну, бывает, чего уж там. Разработчик торопился, быстро сохранил в текстовичок, и дальше, мол, грепайте в нем сколько хотите. Ну, раз нашел, в чем дело, то надо бы и исправить, ведь так? Это и было Игорем сделано в двух pull-реквестах на GitHub (раз и два). В результате простой переход на базу с SQL-языком резко ускорил процесс:

# Было
$ time grep -E ^tex /var/cache/dnf/available.cache
real    0m0.112s
user    0m0.017s
sys    0m0.043s

# Стало
$ time sqlite3 packages.db "select pkg from available WHERE pkg LIKE \"tex%\";"
real    0m0.018s
user    0m0.008s
sys    0m0.010s

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

Мы никогда не устанем рассказывать, что эффективное бинарное хранение данных всегда будет гораздо выгоднее текстовичков. Например, люди даже пишут специальное ПО, чтобы преобразовывать текстовые логи Apache в базу с SQL-запросами. А казалось бы - удобно глазами читать, не нужно никаких утилит (вы же помните - любители юниксвэя, это сплошь киборги, воспринимающие информацию прямо с секторов жестких дисков). В нашем случае произошло тоже самое - переход на бинарное хранение оказал заметное ускорение. Теперь автодополнение при установке пакетов просто летает!



Попутно, Игорь, пробежавшись глазами по коду сопутствующих проектов увидел вопиющие нарушения рекомендаций Process Identifier Preservation Society. Исправил и это (раз и два), что тоже привело к заметному ускорению. Разработчик схватил идею на лету, и оставшиеся проблемы исправил уже сам.

По результатам разборок с этими багами и дебиановцы себя чувствуют теперь у нас комфортнее, и проблему исправили, и разработчику помогли, да еще и научили его полезному навыку - сколько зайцев сразу!