Re: [dev] dmenu_path rewrite in C

On 19 May 2010 10:58, Elmo Todurov <todurov_AT_gmail.com> wrote:
> 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.

Yes I meant reading the cache.

> 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

The cache is up-to-date is the usual case I would say. The the
difference isn't huge.

> 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

Well and these measures will differ quite a lot from system to system.

> 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.

I understand that, though one could argue poor user setup if path
contains duplicates ;)

>> The question is though, if it really
>> justifies a native tool in mainstream dmenu ;)
>
> You're the judge...

Heh, well I'm happy to put everything into mainstream dmenu that makes
sense and keeps it simple and brings a noticable difference and
improvement.

For the time being I propose you to announce this tool on the wiki and
ask more people to test it, just to see if there are issues and we can
decide at a later point what to do, especially if it has a bigger
userbase ;)

Another headache I have about it is perhaps the "too-many"
special-purposefulness of it, but on the other hand reinventing find
would also be pointless.

Having said that, one of my least worries is about performance after
all. Theoretically dmenu_cache becomes 2 or 3 times faster every
18months or so without changing it ;)

>> 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.

Ok

>> for simplicity and clarity
>> reasons we always reverted to the current solution.
>
> A noble cause.

Yes ;)

Cheers,
Anselm
Received on Wed May 19 2010 - 10:14:11 UTC