Технічна перевага Beancount над Ledger, hledger та GnuCash
Вибір персональної системи бухгалтерського обліку передбачає компроміс між продуктивністю, архітектурою даних та розширюваністю. Для інженерів та інших технічних користувачів вибір часто зводиться до того, яка система забезпечує найбільш надійну, передбачувану та програмовану основу.
Спираючись на детальний порівняльний звіт, давайте проаналізуємо технічні особливості Beancount у порівнянні з його популярними аналогами з відкритим кодом: Ledger-CLI, hledger та GnuCash.
Швидкість та продуктивність: Кількісні показники 🚀
Для будь-якого серйозного набору даних продуктивність є невід'ємною складовою. Beancount розроблений для обробки даних про транзакції за десятиліття без шкоди для швидкості. Незважаючи на те, що він реалізований на Python (v2), його високооптимізований синтаксичний аналізатор надзвичайно ефективний.
- Beancount: Реальне використання показує, що він може завантажувати та обробляти книги обліку з сотнями тисяч транзакцій приблизно за 2 секунди. Використання пам'яті є помірним; аналіз ~100 тис. транзакцій перетворює вихідний текст на об'єкти в пам'яті, використовуючи лише десятки мегабайт оперативної пам'яті.
- Стрес-тест на 1 млн транзакцій: Тестування з використанням синтетичної книги обліку з 1 мільйоном транзакцій, 1000 рахунків та 1 мільйоном записів про ціни виявило значні архітектурні відмінності:
- hledger (Haskell): Успішно завершив повний аналіз та звіт за ~80,2 секунди, обробляючи ~12 465 транзакцій/сек, використовуючи ~2,58 ГБ оперативної пам'яті.
- Ledger-CLI (C++): Процес було завершено через 40 хвилин без завершення, ймовірно, через відому регресію, що спричиняє надмірне використання пам'яті та процесора з дуже складними книгами обліку.
- Beancount: Хоча він не був включений до цього конкретного тесту на 1 млн, його крива продуктивності свідчить про те, що він би ефективно впорався із завданням. Крім того, очікується, що майбутній Beancount v3 з його новим ядром C++ та Python API забезпечить ще одне покращення пропускної здатності на порядок.
- GnuCash (C/Scheme): Оскільки графічний додаток завантажує весь набір даних у пам'ять, продуктивність помітно знижується зі збільшенням розміру. XML-файл розміром ~50 МБ (що представляє понад 100 тис. транзакцій) відкривався 77 секунд. Перехід на серверну частину SQLite лише незначно покращив це до ~55 секунд.
Висновок: Beancount забезпечує виняткову продуктивність, яка масштабується передбачувано, що є вирішальною особливістю для довгострокового управління даними. Він уникає падіння продуктивності, яке спостерігається в Ledger, та затримки, пов'язаної з інтерфейсом користувача, в GnuCash.