Re: To Discuss: Application Startup Time

[Andy Ross <andy plausible org>]

[This is a late submission to the discussion.  I'm not a subscriber and
just noticed the thread in the archives.]

Fabio Gomes wrote:
> I would like to bring up a discussion on how we could make
> GNOME applications start faster, at hacker level and user
> level.

Havoc Pennington replied:
> Not to be a smartass, but the discussion is very short ;-)

Soeren Sandmann noted:
> Well, the discussion is short if you limit it to "profile and
> optimize", but it isn't obvious what kinds of profiling and
> optimization are needed.

Fabio Gomes wrote again:
> To isolate the problem, I will first profile the initialization
> functions of the GNOME libraries, as pointed out by Sridhar.

Well, sure.

Or you could just run gedit under strace.  No need for fancy
profiling tools, just watch the output and you'll see immediately
where the problem is.

It's slow because it spends time walking through a zillion icon
directories at a dozen resolutions and stating every file it sees (via
getdents()).  I see 500+ directory opens, with maybe a few dozen files
in each.  That's going to thrash an awful lot of disk sectors.

The icon directories are huge.  Linearly searching through them for
path lookup just isn't going to work if fast startup times are
required (starting gedit a second time with a pre-primed disk cache is
quite fast, about twice as fast as a equivalently primed emacs on my
box).  Some kind of cooked or indexed representation is needed.  This
is the same problem that tools like depmod/ldconfig/prelink/etc... are
designed to solve.

Note that I'm not a gnome guy.  I found this while browsing through
the archive and thought I could help with the diagnosis.  I don't have
any clear ideas on where to put the index and obviously can't write
the code.  Some options:

+ Globally in the filesystem, a-la mkfontdir or ldconfig.  Has to be
  run by hand when new icons are added.
+ Per-user, as a local index.  You can then just stat the directories
  (and not their contents) to detect new files.
+ On the X server as root window properties.  The first app takes the
  hit, and future ones just use the cached pixmaps.

And while we're on the subject: has anyone else noticed that the Panel
has exactly the same icon-loading issue?  But it's much worse there,
because it appears to lazy-load the menu contents.  The first time you
open each panel menus (or sub-pane) the disk thrashes and it takes a
just-large-enough-to-be-really-annoying time to open.  This drives me
nuts. :)

Andy