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 <[email protected]> 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. > _______________________________________________ gnucash-user mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
