Slingshot is sometimes slow to show up

Strace of file calls shows a lot of stat() which should not be issued on opening Slingshot. Inotify watches should be used instead of polling all those files every time Slingshot is opened.

fatrace trace #2 also shows a lot of direct icon access requests. Does that mean that our icon theme cache doesn't work?

While this bug still remains valid, I've tried with latest revision and the wait is surely more than normal, but still very little, under 1 second on my Core 2 Duo with 2GB of RAM and not-so-fast hard disk.

Well, there were only translation updates since r264 which I tested till the latest r267, so I can't see how could that affect Slingshot performance, especially since the .mo files are not accessed on revealing it at all.

2,2 seconds on my system that's running from an external HDD.
Don't forget to drop page cache by running "echo 1 > /proc/sys/vm/drop_caches" in a root shell before testing.

Yeah, I dropped the cache, it's just that probably the first time I've tried my system was already slowed down by something else.
I'm not saying this shouldn't be important, indeed if it's not fixed for beta1 it'll surely be for beta2, just that it has medium importante, not high as I previously stated.

Here are strace timings for the gmenu3 branch. It still has the same performance issues. I've included timings too (time difference between the beginning and the end of each system call, not CPU time). Slingshot performs a lot of stat() calls but according to the timings, time spent in them is negligible. Weird...

Thanks for the profiling information Sergey!

File accesses during first run are completely normal. Nearly 90% of them are related to icon files. Slingshot (GTK+) usually has to load from 16 to as much as a hundred icons depending on how many applications you've installed. I would rather associate this lag to the drawing internals of the popover widget: The BufferSurface class on which the widget relies for drawing is not fast (and it's not supposed to be, according to the documentation). It is fine for small popovers (say 250x150px), but it gets worse when the popover area becomes bigger.

It's not about first run, it's about opening it after it has already started up completely.
I'm sure the lag is linked to the filesystem cache state - if it has the relevant files, Slingshot shows up quickly; if I drop the cache, it takes a while to show up.

Just a note: I noticed a significant increase in Slingshot's loading time after installing a bunch of random apps (I now have 6 pages). There is definitely a delay between hitting the applications item on WingPanel (or hitting the shortcut) for the first time after logging in and Slingshot opening.

Is there some way to load the other pages after the first one so that the launch is always super fast? It should be nearly instantaneous.

Cassidy, you mean on startup or even after?

Are we really sure there's a problem here? I know little about this kind of things, so I could be missing something obvious, but in my machine (not, when dropping cache, Slingshot take only a little while more than normal and is still a reasonable time. See http://youtu.be/2IilhxUGjC4 for the screencast. Plus, if the filesystem cache is dropped is to free ram to avoid swapping, so are we sure is a great idea to add another cache which doesn't free when asked by the system? I'd prefer a slower Slingshot than a slower system.

Even after initial startup, each time the user reveals Slingshot it issues... gosh, 38 disk lookups via stat() syscalls! Such amount of random disk reads creates a noticeable delay on HDDs, although it goes unnoticed on e.g. LiveUSBs which have no seek time.

Please find attached a list of directories on which the stat() syscalls are performed. They should be replaced with inotify watches.

Maybe you're experiencing the slowness that I was. I dont think it's a disk/cache issue.

Try building from source using https://code.launchpad.net/~tigrangab/slingshot/testing-startup-time and see if that has an improvement for you.