I am not aware of any that does. With modern hardware, and in a personal finance context (a few transactions per day), it is unlikely you will have too much data to handle. The algorithm to compute a balance is O(n) with the number of transactions, or O(nlogn) if the tool allows for unsorted input.

If required, you could always close a balance in one file and start with new accounts in a new file, sharding your journal by year, for example.

It would be good to measure that for the various tools. Things like balance assertions, balance assignments, valuation, may complicate the picture. hledger and beancount users, at least, do often split files by year to keep things in the "pleasantly fast" range.

> If required, you could always close a balance in one file and start with new accounts in a new file, sharding your journal by year, for example.

When I was using double entry accounting down to individual grocery items in GNUCash, I used to do this just for my own sanity.

Essentially yes, with some exceptions:

Ledger used to save a parsed/processed file to speed up subsequent reads. It was dropped as not being worthwhile.

Long-running UIs, like hledger-ui, hledger-web, and fava I expect, do the parsing only once, though the report calculation is typically repeated on each page load.