Hi all,

On Monday, there was a brief discussion on irc about the GIMP startup
time when the files are fetched over NFS.  Using NFS or any other
remote file system, all read/writes/stats are more expensive than from
a local disk.  The discussion was about what could be improved to make
the GIMP load faster.  I initally thought that some of the delays that
are more visible over NFS were due to the way all plug-ins are
stat()'ed to check their timestamp, but the test results included
below show that I was wrong.  So I would like to share these results
with those would could be interested (I am unable to re-join irc for
the moment).  Note that the discussion was about the time that it
takes for the GIMP to scan all its plug-ins, brushes, patterns, and
other data files (i.e., the time during which the splash screen is
shown) and not about the time taken to open an image, create the menus
or related stuff that is found in Bugzilla.

I made some tests from a rather old Sun Ultra10 box running Solaris 8,
which is connected over 100Mbps Ethernet to an old NFS server
containing the GIMP installation and to another slightly faster NFS
server hosting my home directory.  Using the Solaris "truss -d"
command (similar to "strace -tt" for Linux), I timed the startup time
of the gimp-2.0, the stable version that I installed on our NFS
server.  I created a first trace file on Monday (about 2.5 MB of trace
messages), which I uploaded to:
http://wilber.gimp.org/~raphael/gimp-2.0-solaris-syscalls.txt
That file was good but not perfect because a few files were still in
the NFS cache when I did the test, so I re-did a new trace later.
Unfortunately I cannot upload it for the moment because I have some
problems accessing wilber.gimp.org, but the results are not very
different from the previous run.

Here is a summary of the timings (from the new file, unfortunately):
- from 0 to 1.76 seconds: loading of the app and all libs (gtk, X11...)
- until  3.24 (diff: 1.48): X client init, connection to X server
- until  5.23 (diff: 1.99): get pixbuf loader, load splash, init pango,
                            get font, display splash
- until  5.43 (diff: 0.20): load environ, parasiterc, init progress bar
- until  6.34 (diff: 0.91): load 48 brushes
- until  7.05 (diff: 0.71): load 58 patterns
- until  8.24 (diff: 1.19): load 39 palettes
- until  8.76 (diff: 0.52): load 78 gradients
- until  9.55 (diff: 0.79): load fonts, templates, modules, sessionrc...
- until 12.07 (diff: 2.52): load tool presets
- until 12.24 (diff: 0.17): stat all plug-ins
- until 12.69 (diff: 0.45): read pluginrc
- until 14.63 (diff: 1.94): update progress bar during init of 156 plug-ins
- until 25.75 (diff:11.12): pipe & fork script-fu, init 95 scripts and pdb
- until 30.56 (diff: 4.81): read menurc, devicerc, final init, display docks
- after that, the GIMP is idle for some seconds and then I close it

I repeated the same test several times, waiting a couple of hours and
doing some other tasks between each test in order to flush the NFS
caches (client and server).  In all cases, the startup time was around
30 seconds (between 30.1 and 30.6) so the test can be reproduced
easily and the results are consistent.

Some comments:
- It takes about 5 seconds until the splash is displayed, but it would
  be difficult to improve that time because most of it is spent
  loading the main executable and libraries over the network.  It
  would be possible to show a splash screen earlier by using some
  hacks such as loading it from a small statically-linked executable
  written only for that purpose but this is not worth the effort IMHO
  (some commercial apps do it that way).
- The gih brush loader could be improved because it reads its files
  one byte at a time, but that has only a minor impact on the overall
  delay (the whole brush file is cached locally anyway).  We could not
  save more than a fraction of a second by improving this.
- Loading palettes is slower than I expected.  Not a problem, though.
- Loading tool presets is slower than I expected.  The time is spent
  in the GIMP itself and not loading the very small files, so NFS is
  probably not making much of a difference here.
- Doing the stat64() for all plug-ins is faster than I expected, so
  this is not the main cause of delays as I thought initially.
- Initializing script-fu takes a lot of time (more than 10 seconds),
  mostly due to the large amount of inter-process communication.  This
  delay is not related to NFS.  It would probably be similar on a x86
  machine running at less than 500MHz.
- If most files are already in the local NFS cache before starting the
  GIMP, then it starts about 7 seconds faster (23 seconds instead of
  30 seconds).

Conclusion: the additional delay due to potentially inefficient usage
of NFS is not that big, if we keep in mind that it would be difficult
to reduce the initial loading time for the main app and libs.  The
other potential optimizations are not specific to NFS.

-Raphaėl

P.S.: I actually wrote this message yesterday but completed it with
      additional tests performed today.  Sorry if I mixed yesterday
      and today in the text.
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to