Re: [dev] dmenu_path rewrite in C

From: Premysl Hruby <dfenze_AT_gmail.com>
Date: Wed, 19 May 2010 12:09:33 +0200

On (19/05/10 12:58), Elmo Todurov wrote:
> Date: Wed, 19 May 2010 12:58:16 +0300
> From: Elmo Todurov <todurov_AT_gmail.com>
> To: dev mail list <dev_AT_suckless.org>
> Subject: Re: [dev] dmenu_path rewrite in C
> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9)
> Gecko/20100330 Shredder/3.0.4
> List-Id: dev mail list <dev.suckless.org>
>
> 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

That's such a small difference... current shell solution caching is IMHO
fast enought.
>
> 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.

Well, I (and others possibly) have no concern about cache miss, my files
in $PATH doesn't changes every five minutes :-)

So, I see no reason to have it "mainline".

-Ph

-- 
Premysl "Anydot" Hruby, http://www.redrum.cz/
-
I'm a signature virus. Please add me to your signature and help me spread!
Received on Wed May 19 2010 - 10:09:33 UTC

This archive was generated by hypermail 2.2.0 : Wed May 19 2010 - 10:12:02 UTC