On 11/16/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote:
> On 11/15/06, Myrddin Emrys <[EMAIL PROTECTED]> wrote:
> > When autocompleting, it takes far longer than it seems like it should. For
> > example, I have 5 files in my home directory (10 counting .files). If I type
> > "~/c", and then press tab, it takes a full 3 seconds to complete the single
> > possible match. I do have a slow computer (P800), but doing a listing of my
> > home directory only takes half a second at most... the autocomplete should
> > take no longer. The output from 'ls ~/c*' is nearly instantaneous.
> >
> > Even if I do the autocomplete twice in a row (no hard drive seeking the
> > second time) it still takes a full 3 seconds to autocomplete. It's doing a
> > heck of a lotta processing for such a simple task... I think the algorithm
> > is searching things it need not search.
>
> You are right - something is taking far too much time. This was
> definitely not always the case - I'll look into it.
I've looked into this. The thing that is taking up time is using
apropos to try and get a description of each possible command. In the
case of completing '~/c', this part can often be optimized away.
Chances are that ~ will not contain any programs, only directories. I
added a check so that if we only have directories and no commands as
completion targets, the description lookup is not used. But the
problem that getting command descriptions is slow is still there in
the general case.
You can disable description lookup by redefining the
__fish_describe_command function:
function __fish_describe_command; end; save_function __fish_describe_command
The original function looks like this:
function __fish_describe_command
apropos $argv | awk -v FS=" +- +" '{
split($1, names, ", ");
for (name in names)
if (names[name] ~ /^'"$argv"'.* *\([18]\)/ ) {
sub( "( |\t)*\\\([18]\\\)", "", names[name] );
print names[name] "\t" $2;
}
}'
end
If anybody wants to take a stab at making it faster, feel free to do
so. I seem to remember Martin Bähr thinking about this.
The main route for optimization that has been discussed comes from the
fact that on most systems, the output of apropos is sorted, and the
output only contains one key on every line. If we assume this propery,
we can do a binary search instead of a full filtering of the output as
is currently done. 'apropos . >/dev/null' takes ~.01 s on a 300 MHz
system, a binary search should take virtually no additional time, so
this should improve performance quite a bit. We could add a script
that on the first call to __fish_describe_command checks if the output
is sorted with one key per line, and if so uses a binary search. That
way we would get high performance and a completion system that works
well for everyone.
Any takers?
>
> >
> > Myrddin
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >
> > _______________________________________________
> > Fish-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/fish-users
> >
>
> --
> Axel
>
--
Axel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
