Gnucash file is getting long!
R. Victor Klassen
rvklassen at gmail.com
Sun Jun 18 06:53:48 EDT 2017
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.
>
More information about the gnucash-user
mailing list