Alright 
On Friday, 20 March 2026 at 01:12:37 UTC+6 [email protected] wrote:

> 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).
>
> On Thursday, March 19, 2026 at 2:19:31 PM UTC-4 Chary Ev2geny wrote:
>
>> 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 
>>
>> On Thursday, March 19, 2026 at 5:56:07 PM UTC+1 [email protected] 
>> wrote:
>>
>>> 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?
>>>
>>>
>>>

-- 
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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/beancount/8123cb3b-ef4d-4550-8d22-851c304640bfn%40googlegroups.com.

Reply via email to