Now, I have an idea here: exebuf does not list _all_ apps _ever_ if you type nothing then the list is empty.
would it be quicker to populate in the background only when something is typed (thus limiting the number of results returned)? Not sure that this would be quicker, but thought I would throw it into the mix... A On Mon, Feb 06, 2006 at 09:33:34AM +0900, Carsten Haitzler wrote: > On Sun, 5 Feb 2006 17:29:37 -0500 Ben <[EMAIL PROTECTED]> babbled: > > > On 2/5/06, Andreas Volz <[EMAIL PROTECTED]> wrote: > > > > > Ok, I'll try this next weekend if no solution was found until then. > > > Perhaps it's an interesting information that it takes nearly the same > > > time if I press TAB-TAB in an empty bash command and the system > > > collects all executables. It's interesting that after I did this the > > > exebuf comes up very fast. > > > > > > > [TAB-TAB] > > > Display all 3225 possibilities? (y or n) > > > > > > Are 3225 executables very much? I tested it on a Debian System with > > > 1049 possibilities and it was _much_ faster (this system/harddisk > > > is also much slower). So perhaps it's usefull to know the distribution > > > of all the people with the same problem. > > > > > > regards > > > Andreas > > > > > > > I don't know that the number would be too many - My system offers 2640 > > possibilities, but only takes 1-2 seconds to tell me that, doesn't > > seem like the extra 600 entries should add all the additional time you > > are encountering. Like Raster mentioned before, something with your > > path or disk (fragmentation?) could be fubar'ed. > > indeed. exebuf is doing pretty much just what bash/zsh/etc. woudl do when u do > tab completion. no different really in principle. in order to find mathces it > will at the MINIMUM have to list all executables. exebuf does this as a > one-off > when it first comes up so it's in memory while exebuf is up. it's really a > matter i thnk of your fs being pretty screwed. your disk is slow - and/or fs > is > slow and/or your disk is so fragmented that in order to list all these files > and simple stat them to check if they are executable or a directory etc. does > so much disk churning that it takes a significant amount of time to do. > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://sel.as-us.falkag.net/sel?cmd_______________________________________________ > > enlightenment-users mailing list > > enlightenment-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] > 裸好多 > Tokyo, Japan (東京 日本) > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- To iterate is human, to recurse divine. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
