Gnucash file is getting long!

[R. Victor Klassen]

For interactive use disk I/O is fast compared to the time waiting for keystrokes.

Only for importing and possibly report generation would disk I/O be a bottleneck.

Currently the file size slows down startup because the entire file is read and interpreted into memory.
If the file were simply a memory image (not that I’m suggesting it should be) it could be read in one gulp, which would be barely noticed.

In a true database implementation (which I understand is the direction it is moving) only that part needed to re-build any currently open tabs would need to be read and converted into the internal data structure, which, I suspect, would also be so fast as to be barely noticed, and show negligible dependence on the file size.


> On Jun 17, 2017, at 4:35 PM, AC <gnucash at acarver.net> wrote:
> 
> Well ok, it makes many insert/update/appends and then the transaction
> causes a pile of writes.  The disk I/O is still the bottleneck for most
> applications.
>