XML size (was: no subject)

[Derek Atkins]

Paul Lussier <plussier@mindspring.com> writes:

> But what are you speeding up?  Load time and save time?  How often do 
> those two actions occur?  I would be all for it if you were talking 
> about speeding up re-display after a transaction entry event, that 
> happens quite frequently within any given session.  But load time 
> occurs once per session.  Saving?  Okay, that happens more 

While I was home with my parents last week I watched my mom use
Quicken and Quickbooks.  During the time I was there she had to enter
5 items.  She entered those five items in 3 sessions.  Each session
included a startup, data entry, and shutdown.

So yes, speeding up startup and shutdown _is_ important.  Not everyone
leaves their Gnucash running 24/7.

> And regardless, it's not like you're going to need a 1.5Gig CPU and
> a 1/2Gig of RAM to run GnuCash.  I'm on a PII 300 with 96MBs of RAM.
> The "average" user has a much more beefy machine than that.  I run 
> GnuCash on my PII 200 laptop with the same data set and other than 
> maybe a 10 sec load time (at most, I've never actually measured it)
> I don't find it slow or even sluggish.

Note that even when you double your CPU, the SQL implementation will
_still_ be faster than the flat-file implementation! :) Sure, the time
to startup using SQL on a P-III 500Mhz will appear to be the same as
XML on a P-III <greater-than-500MHz> machine, but on this second
machine the SQL implementation will be even faster...

This is the red herring of "get a faster machine".  While the slower
algorithms will appear be improved with the faster machine, your
faster algorithms will appear _even faster_.  In order to get to a
state where slower algorithms appear just as fast as faster algorithms
you need so much speedup as to make those algorithms both take
'epsilon' time when compared to the other operations being done.

> I would make it modular and optional.  There is already the option to 
> build GnuCash with SQL/PostgreSQL support, but it's not required.
> Businesses, or those individuals who wish to use this support may. 
> Those who don't have that option as well.  Why does this need to 
> change?

Code-size.

We can reduce the code in gnucash by just requiring the external
dependency.  This particular reduction in code size would both:
        a) speed up the runtime, and
        b) reduce complexity

> >> Ahm, everything is data, some is just accessed and used differently or 
> >> more often than others.
> >
> >I disagree.  HOW the "data" is used is extremely important.  But
> >perhaps we must agree to disagree.
> 
> I didn't say that how it was accessed wasn't important.  I said 
> that everything was data.  You (or someone) made the statement that
> 
> 	configuration != data
> 
> when in fact, configuration data is still data, it's just accessed
> and used *differently*.  I totally agree that understanding HOW it's 
> used or accessed is extremely important.

My point was that understanding how it's used and accessed means you
can make decisions about the format.  Configuration is accessed in a
way that humans should be able to edit it themselves.
Non-configuration data, otoh, should be optimized for application
usage.

> Seeya,
> Paul

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available