[dwm] [dmenu] help me test possibly faster dmenu_path
I theorize that find outperforms for/test. Below are two shell scripts:
if you run the first one it will let you know the results of two runs.
The second one is a modified dmenu_run that uses find. I'd appreciate
it if people would run the first one and mail the results to me. I'll
let the list know what the results are.
Here are my results:
$ bin/fstest
=== find_binaries 1
real0m0.037s
user0m0.005s
sys 0m0.013s
=== find_binaries 2
real0m0.024s
user0m0.003s
sys 0m0.015s
=== shell_binaries 1
real0m5.099s
user0m0.469s
sys 0m0.185s
=== shell_binaries 2
real0m0.476s
user0m0.401s
sys 0m0.059s
On my system, the find version is 137 times faster before the OS has
cached the directories, and 19 times faster when directories are cached.
This is in part due to lots of symlinks pointing outside my path, but
mostly because find is more efficient.
-8- findtest -8-
#! /bin/sh
SPATH=$(IFS=:; for dir in $PATH; do echo $dir; done)
shell_binaries () {
for dir in $SPATH; do
for file in $dir/*; do
test -x $file echo ${file##*/}
done
done /dev/null
}
find_binaries () {
find $SPATH -maxdepth 1 \( -type f -o -type l \) -perm +111 -printf %f\n
/dev/null
}
echo === find_binaries 1
time find_binaries
echo === find_binaries 2
time find_binaries
echo === shell_binaries 1
time shell_binaries
echo === shell_binaries 2
time shell_binaries
-8-
-8- dmenu_run -8-
#! /bin/sh
binaries() {
SPATH=$(IFS=:; for dir in $PATH; do echo $dir; done)
find $SPATH -maxdepth 1 \( -type f -o -type l \) -perm +111 -printf %f\n
2 /dev/null
}
exec $(binaries | sort | uniq | dmenu $@)
-8-
Re: [dwm] [dmenu] help me test possibly faster dmenu_path
Neale, 2008/12/17 Neale Pickett ne...@woozle.org: I theorize that find outperforms for/test. Below are two shell scripts: if you run the first one it will let you know the results of two runs. The second one is a modified dmenu_run that uses find. I'd appreciate it if people would run the first one and mail the results to me. I'll let the list know what the results are. Similiar tests have been done a while ago, however we decided for the shell-only version for various reasons. First of all you are referring to GNU find as far as I can tell, however the BSD find is slightly different (same applies to Solaris), then there was an issue with softlink following and something else which resulted in displaying executables which were not intended to show up, the refresh testing and maybe another issue I don't remember right now (it's all in the mail archive somewhere). Of course find is faster, however I don't intend to change the shell only solution since we got cached results... Kind regards, --Anselm
Re: [dwm] Border hater, border lover
2008/12/15 Anselm R Garbe garb...@gmail.com: 2008/12/14 voltaic volt...@gmail.com: It seems this idea was forgotten again, so I thought I would bring it up once more. As DWM 5.4 is being finalized and there is discussion on what to include in future versions, I'd love to see the no-border-if-single-window behavior become mainstream. Agreed, will push a patch accordingly during the day. It's in. Please recheck if there are any issues. Otherwise I'm going to release 5.4 tomorrow. Kind regards, --Anselm
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
Re: [dwm] Border hater, border lover
2008/12/17 Anselm R Garbe garb...@gmail.com: It's in. Please recheck if there are any issues. Otherwise I'm going to release 5.4 tomorrow. Two things (of not too much importance, anyway): 1. What about the applyrules modification discussed in http://lists.suckless.org/dwm/0812/7057.html ? 2. IMO the issingle variable name in adjustborder() should be changed, e.g. to hasborder. I will elaborate on #2: I'm using a modified monocle where the border is removed when the status bar is not visible, so that I have some kind of fullscreen layout (very useful for firefox video windows from some sites). When I have seen this new function I thought that it would perfectly fit in this function (maybe it could even go into main? I think it will be just one more line), but issingle doesn't make too much sense then. Anyway, as I told, nothing important... -- - yiyus || JGL .
Re: [dwm] Border hater, border lover
2008/12/17 yy yiyu@gmail.com: 2008/12/17 Anselm R Garbe garb...@gmail.com: It's in. Please recheck if there are any issues. Otherwise I'm going to release 5.4 tomorrow. Two things (of not too much importance, anyway): 1. What about the applyrules modification discussed in http://lists.suckless.org/dwm/0812/7057.html ? 2. IMO the issingle variable name in adjustborder() should be changed, e.g. to hasborder. I will elaborate on #2: I'm using a modified monocle where the border is removed when the status bar is not visible, so that I have some kind of fullscreen layout (very useful for firefox video windows from some sites). When I have seen this new function I thought that it would perfectly fit in this function (maybe it could even go into main? I think it will be just one more line), but issingle doesn't make too much sense then. Anyway, as I told, nothing important... -- - yiyus || JGL . I have just realized it wouldn't need a single line of code to remove the border in fullscreen layout (i.e.: monocle + !showbar). Inside monocle, doesn't adjustborder(c, n == 1 || !showbar) make sense to you? Maybe you could also have a new define in config.h, so people can choose: #define MONOCLEBORDER n == 1 #define MONOCLEBORDER n == 1 || !showbar #define MONOCLEBORDER True Anyway, having borders in monocle is probably a matter of taste, but it is so easy adding your own layout that I doubt it is even a matter... PS: I will stop rambling now and will wait for tomorrow release. Good night! -- - yiyus || JGL .
