Re: [dwm] [dmenu] help me test possibly faster dmenu_path

Anselm,

My apologies for bringing up something which has already been discussed,
I didn't think this specific issue would have come up before!

My primary machine (a shared machine on which I don't have root access)
triggers a cache miss nearly every time with dwm_path, due to
directories being constantly updated. This incurs a minimum 4 second
delay, since dmenu_path rebuilds the cache before displaying the cached
output. When I arrive at work in the morning, the delay can exceed 2
minutes.

I may be the only dmenu user with this problem of the cache missing more
often than hitting. But since the find version appears to be up to 20x
faster and simpler, and the only drawback is that symlinks to
non-binaries in $PATH showed up in the menu, I thought it was worth
bringing up here. I don't feel like my dmenu_run needs to be put into
the distribution unless there's overwhelming support for doing so.

My find version did use a GNU-ism, thank you. I've removed that; here's
one that works on GNU find and FreeBSD find (reports on other systems
would be welcome):

        find $SPATH -maxdepth 1 \( -type f -o -type l \) -perm +111 | \
        while read i; do echo ${i##*/}; done &> /dev/null

Additionally, as you point out, the find version has a problem with
symbolic links: if a symbolic link exists in the path, it isn't tested
to see what it links *to*. This is one of the things that provides a
significant speedup for me, since I have at least 10 NFS mounts at any
given time, and following all those symlinks triggers the automounter.
I think the 20-130 times speedup outweighs the rare possibility of a
symlink in $PATH not pointing to an executable.

Thanks,

Neale
Received on Wed Dec 17 2008 - 21:45:59 UTC