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.
