Wed, 03 Apr 2002 17:16:59 -0500
In a message dated: Wed, 03 Apr 2002 14:10:43 EST
Christopher Browne said:
>Editing the existing XML file is not all a bed of roses, by the way.
Never said it was, but the fact that I can if I need/want to, is better
than not being able to at all.
>Frankly, the problem _today_ has to do with neither of these, and will
>not be solved by changing the way data is stored.
>The problem that was had 8-odd years ago with CBB
(has it been *that* long? Crikey, seems like yesterday :)
>which continues today, to some extent, with GnuCash is that the
>_display widget_ performs increasingly poorly as the amount of data
>associated with the register increases.
>With CBB, that was the Tk "array" widget, where modifying anything
>required recomputing the whole array, because it wasn't smart enough to
>know to change just those bits that actually changed.
>With GnuCash, changing the date on a transaction could lead to a whole
>cascade of data changes if that change moved a transaction from bottom
>to top. Every balance along the way could need recalculating, for
Okay, this makes a lot more sense to me now. However, how would
changing the under lying data format from ascii to binary affect this?
Doesn't the application still need to make all the same screen
updates were the same change made? Are you saying that by pushing
the calculation engine outside of GnuCash to a DB would somehow speed
things up with respect to how fast the display could update?
I definitely agree that by pushing things out to a backend database
would lessen the amount of code required in GnuCash ( I don't like
it, and I don't want to see it happen, but I agree with the
statement). But I don't understand how that will affect screen
updating. Doesn't the application still need to read in the same
amount of data and display the same bits on the screen?