L'avantatge tècnic de Beancount vs. Ledger, hledger, i GnuCash
Escollir un sistema de comptabilitat personal implica compromisos entre el rendiment, l'arquitectura de dades i l'extensibilitat. Per als enginyers i altres usuaris tècnics, l'elecció sovint es redueix a quin sistema proporciona la base més robusta, predictible i programable.
A partir d'un informe comparatiu detallat, analitzem les especificacions tècniques de Beancount enfront dels seus homòlegs de codi obert populars: Ledger-CLI, hledger i GnuCash.
Velocitat i rendiment: Benchmarks quantitatius 🚀
Per a qualsevol conjunt de dades seriós, el rendiment no és negociable. Beancount està dissenyat per gestionar dècades de dades transaccionals sense comprometre la velocitat. Tot i estar implementat en Python (v2), el seu analitzador sintàctic altament optimitzat és notablement eficient.
- Beancount: L'ús en el món real demostra que pot carregar i processar llibres majors amb cents de milers de transaccions en aproximadament 2 segons. L'ús de memòria és modest; l'anàlisi de ~100.000 transaccions converteix el text font en objectes a la memòria utilitzant només desenes de megabytes de RAM.
- La prova d'estrès d'1 milió de transaccions: Un punt de referència que utilitza un llibre major sintètic d'1 milió de transaccions, 1.000 comptes i 1 milió d'entrades de preus va revelar diferències arquitectòniques significatives:
- hledger (Haskell): Va completar amb èxit una anàlisi i un informe complets en ~80,2 segons, processant ~12.465 transaccions/seg mentre utilitzava ~2,58 GB de RAM.
- Ledger-CLI (C++): El procés es va finalitzar després de 40 minuts sense completar-se, probablement a causa d'una regressió coneguda que provoca un ús excessiu de memòria i CPU amb llibres majors molt complexos.
- Beancount: Tot i que no s'inclou en aquesta prova específica d'1 milió, la seva corba de rendiment suggereix que gestionaria la tasca de manera eficient. A més, el proper Beancount v3, amb el seu nou nucli C++ i API Python, s'espera que ofereixi una altra millora d'ordre de magnitud en el rendiment.
- GnuCash (C/Scheme): Com a aplicació GUI que carrega tot el seu conjunt de dades a la memòria, el rendiment es degrada notablement amb la mida. Un fitxer XML de ~50 MB (que representa més de 100.000 transaccions) va trigar 77 segons a obrir-se. Canviar al backend SQLite només va millorar marginalment això a ~55 segons.
Conclusió: Beancount proporciona un rendiment excepcional que s'escala de manera predictible, una característica crucial per a la gestió de dades a llarg termini. Evita els penya-segats de rendiment que es veuen a Ledger i la latència lligada a la interfície d'usuari de GnuCash.
Arquitectura de dades: Text pla vs. Bases de dades opaques 📄
La manera com un sistema emmagatzema les vostres dades dicta la seva transparència, portabilitat i durabilitat. Beancount utilitza un format de text pla net i llegible per humans que és superior per als usuaris tècnics.
- Compacte i eficient: Un fitxer Beancount de 100.000 transaccions només té ~8,8 MB. Això és més compacte que el fitxer Ledger equivalent (~10 MB) en part perquè la sintaxi de Beancount permet la inferència de l'import final de saldo en una transacció, reduint la redundància.
- Estructuralment aplicat: Beancount exigeix directives explícites
YYYY-MM-DD\ open\ Account
. Aquest enfocament disciplinat evita que els errors tipogràfics en el nom del compte creïn silenciosament comptes nous i incorrectes, un error comú en sistemes com Ledger i hledger que creen comptes sobre la marxa. Aquesta estructura fa que les dades siguin més fiables per a la manipulació programàtica. - Preparat per al control de versions: Un llibre major de text pla és perfectament adequat per al control de versions amb Git. Obteniu un historial complet i auditable de cada canvi financer que feu.
- Contrast amb GnuCash: GnuCash utilitza per defecte un fitxer XML comprimit amb
gzip
, on les dades són detallades i embolicades en etiquetes amb GUID per a cada entitat. Tot i que ofereix backends SQLite, MySQL i PostgreSQL, això abstrau les dades de la manipulació i el control de versions de text simple i directe. L'edició del XML en brut és possible però molt més feixuga que l'edició d'un fitxer Beancount.
Conclusió: El format de dades de Beancount no és només text; és un llenguatge ben definit que maximitza la claredat, aplica la correcció i s'integra perfectament amb eines de desenvolupador com git
i grep
.