On 05/19/2010 12:42 PM, Anselm R Garbe wrote:
I think the existing shell script based dmenu caching is
already quite fast (assumed the cache exists)
The reason I wrote this is occasional lag when executing dmenu. I'm not
sure I've fixed the problem, though (= Consider it an exercise in
practical tool programming.
> and I doubt that your
native tool does make the cache propagation itself faster.
What does "propagation" mean here? It _does_ make reading the cache
faster. Let me paste my unscientific tests:
When cache is up-to-date:
$ time ./dmenu_path_c 2>&1 > /dev/null
For the C program I get typically
real 0m0.008s
For the shell script I get typically
real 0m0.032s
When cache is old:
rm ~/.dmenu_cache; time ./dmenu_path_sh 2>&1 > /dev/null
For the C program I get typically
real 0m0.047s
For the shell script I get typically
real 0m0.700s
Conclusion: 0.7 seconds is somewhat noticeable lag. It's another
question whether it's worth the effort to write the C program, but hey,
it's been done already.
Also I need to convince myself that your cache creation is really that
much faster, simply because the bottleneck I remember a long time ago
was rather how many executables and PATH directories were visited and
overall filesystem performance.
First, see above. Second, the shell script checks every $PATH item, but
on my (poorly configured?) shell I have duplicates in $PATH. Eliminating
duplicates of course reduces the number of files stat()ed.
The question is though, if it really
justifies a native tool in mainstream dmenu ;)
You're the judge...
As a side note: did you test it with following symbolic links etc? I
very darkly remember a bunch of issues with symbolic links if they
aren't dealt with properly.
Yep. Symlinks are treated transparently, except when they're bad.
for simplicity and clarity
reasons we always reverted to the current solution.
A noble cause.
Elmo
