Re: [dev] dmenu_path rewrite in C

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
Received on Wed May 19 2010 - 09:58:16 UTC