Why does Beancount performance matter?

[Simon Guest]

I have seen a number of people commenting that Beancount is too slow, and there's a desire to see a faster implementation.

I'm not really understanding why this is an issue. Can someone explain please? 

If you load your beanfile and run the plugins and booking algorithm so all the context is sitting in the engine while you make a number of queries, why does it matter if it takes a couple of seconds to be ready to answer queries? 

Or are people running each query as a separate Beancount invocation from scratch?

Or are some queries very slow in and of themselves?

[Chary Ev2geny]

I actually have the same question.

I have 20+ years worth of detailed expenses in beancount. Loading ledger without cash (on updated ledger) takes about 6 sec, with cash 1 sec.

And, as you said, once it is loaded (in beanquery, Fava or in a notebook ), all following analysis is quite fast.

So, taking into account the Moor's law, I have decided, that beancount speed is not going to be a problem for me personally for the rest of my life.

I definitely would not want it to be traded for breaking the API compatibility 

[David Avraamides]

It's not an issue when you are just doing read operations, but one of my normal workflows is a little different. I have a web app with functionality for quickly reviewing, approving, and updating categorization (expense accounts), narrations, and adding additional meta tags (for vacations or other projects). So each time I modify a transaction and update the underlying .bean file, the data needs to be re-read but the .picklecache file is stale so it's a full parse each time. So if I'm reviewing ~150 transactions each month, I might make 50+ edits, each one causing a 3-second delay (I have 50k+ transactions). It quickly gets annoying, but since I do it once a month, it's not terrible.

For the record, I have no interest in switching to a non-Python implementation of beancount just to get improved performance. The benefits of it being Python native far outweigh the parsing speed (for me).

[Martin Michlmayr]

* 'Simon Guest' via Beancount <bean...@googlegroups.com> [2026-03-19 05:36]:

> If you load your beanfile and run the plugins and booking algorithm
> so all the context is sitting in the engine while you make a number
> of queries, why does it matter if it takes a couple of seconds to be
> ready to answer queries?

Because I edit my books all the time, and so the cache needs to be
rebuilt.

Imagine running bean-check after each edit and it takes (say) 5 seconds.

--
Martin Michlmayr
https://www.cyrius.com/

[Martin Blais]

I find it too long, I run bean-check a lot.

In my ideal world, it's running instantly in the background as flymake and provides useful information to Emacs (e.g., inventories) as an LSP with auto-completion (running the balancing rules).

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/beancount/7L0R8coC-pQ0ZCaN7w4KZfxyQOy0f13SafMR_UM_jE6E0Z66Gy1HaWZq4MELK-jafmoh_Jq8M9HUeg0oo8Mi3P4tGiRigwsaCOE3yjhdWAc%3D%40tesujimath.org.

[Justus Pendleton]

> Or are people running each query as a separate Beancount invocation from scratch?

How else would you do it? Do you never script anything? Every query you make is done manually from the bean-query repl?

I have a script that runs:

- bean-download needs-update (a 3rd party script, I can't get all the context sitting in the engine)

- beangulp to import things (ditto, plus "extract" and "archive" operations requires 2 separate invocations)

- autobean-format (though I don't think this actually uses beancount to load entries and does its own thing)

- bean-price (another 3rd party script that requires yet another parsing of all entries)

- several bean-queries to sanity check various things (any flags with !, any vacation not in a leaf account, anything without a payee, etc)

- scripts that build spending trends, net worth trends, graph and chart things.

If each invocation of beancount to parse the entries costs 600ms my script can easily take 6+ seconds to run. That is tolerable but annoying when done on the command line but I've been converting it to a simple web-app to make things more visible for my wife and having to wait 6-10 seconds to load a web page is obviously ridiculous.

[Simon Guest]

Thanks for the replies and the insights. It's pretty much as I thought.

The direction I'm taking with limabean is very much about user experience rather than performance, and it certainly does not position itself for that rapid update cycle use case (at least not for now).

There does seem to be a need for a solution to the update/reprocess cycle that's better than reading the whole input file from scratch though. That seems like a painful process indeed. This kind of partial update is precisely what LSP servers address (and indeed, there is an LSP server for Beancount). Does the LSP approach fall short in other ways?

-------- Original Message --------

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/beancount/20260319231724.GA196249%40panya.cyrius.com.

[Simon Guest]

Ah, with the current generation of tools I think there's nothing else you can do. 

But I'm working on the next generation. So sorry if some of my thoughts seem like a bit of a tease.

I appreciate the discussion. Thank you!

-------- Original Message --------

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/beancount/ff7c7f58-c972-433a-b460-759a07e9d08an%40googlegroups.com.

[Hasibur Rahman]

I think soo

[Hasibur Rahman]

Alright