Engineer.Seeker

От идеи до первой рабочей версии, наверное, пару месяцев. Сначала нарисовал, как это должно быть, укладка структур, поизучал библиотеки. До текущей версии почти полгода. Пришлось много что переделывать, много багов, которые всплывали на момент тестирования.

А также изначально я планировал делать это под Linux, но потом в процессе сменил курс, эта смена тоже не далась легко.

Писал один или с кем-то?

Писал один.

На чём написан проект?

Сердце программы, которое я назвал fastlog. Это модуль, написанный на C++, с эффективным mmap для «тяжёлой» части - индексации, поиска и работы с файлом.

Его я обернул с помощью binding-слоя, чтобы готовый C++ класс можно было пользоваться из Python как обычным Python-объектом.

Для интерфейса Python + Qt6 (PySide6), так как огромная экосистема.

Что было в первой версии?

Первая версия была очень медленной и жрала много памяти, и программа падала с MemoryError. Именно после этого я переписал ядро на C++, где mmap позволяет не читать в память целиком, а отображать в адресное пространство.

Как работает mmap?

Файл отображается в память через mmap - то есть операционная система даёт нам прямой доступ к содержимому, без чтения. Несколько потоков проходят по файлу и запоминают позицию всех символов \n, формируя массив line_offset (байтовое смещение), и таким образом отрезается диапазон. Индексируются именно строки, столбцы не индексируются заранее, а парсятся на лету.

Сколько памяти потребляет?

Память почти не расходуется, в этом и есть прелесть mmap. Файл не читается в оперативку целиком, а ОС держит в памяти только те страницы, к которым недавно обращались. Сама программа занимает память только под индекс, это 8 байт на строку, и лимит - размер адресного пространства.

0,61 секунды - это предел?

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

Как устроен многопоточный поиск?

Файл разбивается на n чанков по количеству ядер (hardware_concurrency), и каждый поток ищет в своём чанке независимо. Результаты объединяются через мьютекс в общий вектор. Ещё, так как потоки могут закончить результат в разное время, то каждый из них работает со своей локальной копией результата, чтобы не блокировать, после они сортируются. Есть atomic для досрочной остановки поиска.

Что было тяжелее всего?

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

Какие были баги?

Было много багов, крайне. Что-то пришлось переписывать на лету. Баги были как и в core, где результаты поиска, например, выводились в неправильном порядке, так как потоки поиска добавляли свои результаты в общий вектор в разное время, а порядок был недетерминированным, так и баги в графической визуализации, где использование Qt создавало свои проблемы.

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

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

Как парсятся данные?

Для парсинга данных используется стандартная библиотека регулярных выражений, так как писать свой движок регулярных выражений - задача на годы.

Чего пока нет?

Работать с разными кодировками, кросс-платформенность, создать что-то типа хранения для внутренних скриптов, и подключить ИИ-агента для анализа логов.

UTF-16 и другие широкие кодировки, очень длинные строки могут замедлить отображение.

Что вырезал?

Сначала я сделал поддержку нескольких столбцов в таблице лога - чтобы можно было щёлкать по строке и видеть разбор CSV. Но потом понял, что это дублирует функциональность вкладки «Анализ». Плюс это усложняло интерфейс.

Чем klogg не устроил?

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

Почему исходники закрыты?

Были [мысли открыть исходники], но пока хотелось бы скрыть эту кухню, по крайней мере пока это тема для меня горячая.

Для кого делал?

Сначала фокус был на меня и с какими проблемами столкнулся я, как аналитик. Далее пытался мыслить шире, расширяя функционал.

Кто первые пользователи?

Я, друзья, чтобы сделать багфикс и что я мог не заметить.

Коллеги знают?

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

Есть фидбек от пользователей?

Пока ещё нет, всё только началось.

Сам пользуешься?

Я использую его в работе и мне комфортно.

Бывает желание всё бросить?

Я думаю, это у всех возникает, особенно когда несколько сборок подряд не фиксят сборку, а делает только хуже.