dmenu2 is occasionally slow to start

gandalf3 · 2015-07-11 06:56:09

Every so often dmenu takes long time to start (>= 5 seconds). There will be a lot of disk activity, like it's re-indexing everything.
This will happen maybe once every half an hour or so, and as far as I know I'm not changing any files in my $PATH.
All other times it appears instantly.

I do appear to have 5127 files that dmenu is indexing:

cat ~/.cache/dmenu_run | wc -l
5127

Not having used dmenu before, I don't know if thats abnormally large or normal.

I'm in openbox, and I'm calling dmenu by pressing the just the super key.
It's caught with xcape (AUR), which turns it into a shortcut openbox can understand (specified in in rc.xml) which runs

dmenu_run -o .9 -b -h 30 -fn '-*-dejavu sans-medium-r-*-*-1-6-*-*-*-*-*-*' -nb "#111111" -nf "#777777"

I doubt it's a problem the way I'm calling it though, as I seem to remember this happening before I set up the shortcut.

The OP on this thread appears to have a similar problem to mine, but no working solution. http://crunchbang.org/forums/viewtopic.php?id=15678

Incidentally whenever I try to adjust the volume by scrolling on the volumewheel icon in tint2 it will occasionally do the same thing (lots of disk access for at least 5 seconds before anything happens).
They aren't quite connected though, if dmenu just re-indexed itself and is now starting instantly, volumewheel may still have a delay.
Is there some kind of caching thing which could cause this sort of behavior? It feels like a caching thing of some kind, as once it's had it's delay it will go instantly (for a while).

intel xeon quad core, 16 GB ram, no swap, openbox, dmenu2 (AUR).

Last edited by gandalf3 (2015-07-11 09:57:51)

jasonwryan · 2015-07-11 07:11:13

5127 is not excessive, I have around the same and only 4 GB of RAM

I am not familiar with the -o or -h options, though...

gandalf3 · 2015-07-11 07:12:43

-o is opacity and -h is height. I believe both are special features provided by the dmenu2 package in the AUR.

jasonwryan · 2015-07-11 07:16:15

Please edit your thread title to reflect the name of the actual package.

Does the same lag happen with vanilla dmenu?

Moving to AUR Issues...

gandalf3 · 2015-07-11 07:20:54

I'll test it an see. I expect it will, but I'll need to let it sit for a bit and give it a chance to do whatever strange cache invalidating things it does.
It did the delay thing on the first run, but that's probably expected.

gandalf3 · 2015-07-11 09:57:37

Interesting, it appears that vanilla dmenu indeed works fine.

Edit: I wonder if perhaps it's specifically caused by one of the options I enabled in dmenu2? That would be weird.. But you never know.
I'll try running dmenu2 without any options for a bit and see if the lag comes back.

Last edited by gandalf3 (2015-07-11 10:18:26)

jasonwryan · 2015-07-11 10:11:32

I patch mine for XFT and file completion: neither has a deleterious impact upon performance. Something in the AUR version you are using does.

Please, as I asked above, edit your thread title to include the exact name of the package you are using.

gandalf3 · 2015-07-11 10:14:26

I did, I'm using dmenu2: https://aur.archlinux.org/packages/dmenu2/
Sorry for the confusion..

Arch Linux

#1 2015-07-11 06:56:09

dmenu2 is occasionally slow to start

#2 2015-07-11 07:11:13

Re: dmenu2 is occasionally slow to start

#3 2015-07-11 07:12:43

Re: dmenu2 is occasionally slow to start

#4 2015-07-11 07:16:15

Re: dmenu2 is occasionally slow to start

#5 2015-07-11 07:20:54

Re: dmenu2 is occasionally slow to start

#6 2015-07-11 09:57:37

Re: dmenu2 is occasionally slow to start

#7 2015-07-11 10:11:32

Re: dmenu2 is occasionally slow to start

#8 2015-07-11 10:14:26

Re: dmenu2 is occasionally slow to start

Board footer