On 19 May 2010 10:58, Elmo Todurov <todu...@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
