Startup time

Tue Aug 18 17:52:35 EDT 2009

It seems to me that there might be a disconnect in what "Loading a report" means.

On the one hand, there is loading a report on startup to allow it to appear in the menus. This appears to go quickly on my machine.

On the other hand, there is loading a report that was open when Gnucash closed previously. This second type of loading can take quite a bit of time, depending on the report and the size of the file. Some reports (Account Balances, Cash Flow [IIRC]) can take a heck of a time to calculate. If you leave a number of these report tabs open when you close GC, the next startup can be quite time consuming. That's why I have tended recently to close as many of these as possible. 

Unfortunately, there are situations where the only way a user can retain a report is to leave it open from session to session. The last I heard, multicolumn reports fall into this category.

FWIW, on my Macbook Pro (OS X 10.5.8, Fink), I have noticed that there is a 30-second delay in startup--before the splash screen even comes up. I suspect that this is a delay caused by the startup of X11, but it sure is disconcerting. If it is X11's fault, I look forward to the day I can spend the time to follow the directions to get Gnucash to run directly under Quartz.

Cheers,
David

--- On Mon, 8/17/09, Derek Atkins <warlord at MIT.EDU> wrote:

> From: Derek Atkins <warlord at MIT.EDU>
> Subject: Re: Startup time
> To: "hasmeta at yahoo.com" <hasmeta at yahoo.com>
> Cc: gnucash-user at gnucash.org
> Date: Monday, August 17, 2009, 7:25 PM
> Hi,
> 
> "hasmeta at yahoo.com"
> <hasmeta at yahoo.com>
> writes:
> 
> >> No, there's no way to load them dynamically upon
> request
> >> because GnuCash
> >> builds the menu items of reports dynamically. 
> This
> >> lets you effectively
> >> drop in new reports and GnuCash will just load
> them and put
> >> them into
> >> the menu for you.  You can't have it both ways,
> and
> >> IMHO being able to
> >> dynamically add reports is more important.
> >> 
> >
> > I may be over my head in the internals of the
> implementation, so
> > correct me if I am wrong, but from what you say, it
> seems that startup
> > code is going through all shared libraries in some
> directory, loading
> > them, then calling some function to get report
> characteristics and
> > then add it to the reports menu. This wouldd explain
> why building a
> > menu of less than 50 items total is taking such a long
> time. And if I
> > wanted to add in an additional report, I'd have to
> copy the shared
> > library into that directory, then restart gnucash so
> that the report
> > would appear on the menu?
> 
> not quite...  The reports are scheme files, not shared
> libraries.  Yes,
> it is loading each scheme file, but that's not a lot of
> time.  The
> shared libraries (GNC Modules) are cached, so it only has
> to load them
> once.  But it does take time to load the module and
> dependencies.
> 
> Seriously, GnuCash is just a large application.  It
> takes time to load.
> Quicken takes time to load.  Quickbooks takes time to
> load.  Open Office
> takes time to load.  MS Word takes time to
> load.   Loading time is just
> a fact of life.  You just need to learn to live with
> it.
> 
> Seriously, how long is it taking to load?  15
> seconds?  20?   Yes, if
> it's taking multiple minutes to load then there's a
> problem, but
> honestly the only time I've seen that happen is due to a
> bug in the
> dynamic loader of some versions of BSD.
> 
> > I am not against dynamically building menu items; my
> point is,
> > building menu items shouldn't take that long. Why not
> cache the
> > results into some text file, and, at next startup, if
> the text file
> > exists, read report characteristics from there
> instead? That way, you
> > can build the menu in a second or less. You could
> repopulate the text
> > file after startup in a low priority thread or put in
> a menu item that
> > says "Refresh Reports" to repopulate the text file and
> recreate the
> > menu.
> 
> If you cache it how do you detect that the cache is
> stale?  Also, I'd
> rather frontload all the loading so that the application is
> responsive
> when I use it, rather than delaying the loading so that
> when I click a
> menu item it takes a significant amount of time to do
> something.
> 
> > I realize that, but it takes noticeably long for the
> perl checker
> > script to load, run and return the results back to
> gnucash: about 4
> > seconds on my Intel Core XP machine. This is a lot of
> time just to
> > determine if a menu item is to be greyed out. Also, a
> greyed out menu
> > item doesn't give any feedback to the user as to what
> may be broken.
> 
> 4 seconds just isn't a large amount of time in the grand
> scheme of
> things.  Seriously.  Also, it's not a matter of
> being broken, but it's a
> feature that isn't instaled.   PERL is a
> heavy-weight application.
> Sorry, there's just nothing to do there.
> 
> > So why not keep it always on? When the user chooses
> it, you spawn
> > whatever perl script is necessary to get the quotes.
> If the process
> > fails, because there's no perl, you say, 'this feature
> depends on
> > perl, please install it'. If the process fails because
> perl couldn't
> > find Finance::Quote in @LIB, you say 'install
> Finance::Quote'. If no
> > internet, 'check internet/proxy settings', so on and
> so forth...
> 
> I think most users would be more annoyed.  I can see
> the email now (in
> fact, I think I've seen it before, years and years
> ago)...  "Hey, why
> can I click on the button if the feature isn't
> available?"  
> 
> You just can't please everybody.
> 
> > Lastly, I appreciate all the effort that the
> developers of this
> > software have put together (and even with a relatively
> longer startup
> > time due to this or that, I am *not* going back to
> Quicken).
> 
> I'm glad you enjoy the program, even if it does take longer
> to load than
> you like.  Honestly, I keep the program open all the
> time.  I start it
> up and I don't close it.  I also make sure to save
> early and save often.
> 
> > --Hasmet
> >
> >> 
> >> > --Hasmet
> >> 
> >> > Please remember to CC this list on all your
> replies.
> >> > You can do this by using Reply-To-List or
> Reply-All.
> 
> -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 at MIT.EDU 
>                
>       PGP key available
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> 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.