Dear Emacs developers:

I tired to find out the issues and provide patches to minibuffer.el and
icomplete.el.

What is the issue?
1. The function completion--flush-all-sorted-completions defined in
minibuffer.el is always called without parameters which make it flush the
cached table every time.
2. The function completion--flush-all-sorted-completions is added to the
hook of after-change-functions, however, (jit-lock-after-change t) in the
hook will trigger flush every time
3. The local cached table completion-all-sorted-completions is not used
actually. The minibuffer-completion-table is called in a lot of function
which will rebuild the table instead of the chached table.

It has small impact on the performance of
1. operation in memory, e.g., describe-variable, describe-function
2. filename in local driver/PC
3. filename in tramp where it works on the ls output instead of trying to
re-do the ls command on the server
Those operations are fast and time for fuctions symbolp and functionp is
ignorable.

However, if it works under some slow instance, for example, a mapped driver
in Window with slow net work, the performance is bad as the completion
tries to list the directory in each call of completion--do-completion and
icomplete-completions, and some other completion functions.

The patches try to use the cached table
completion-all-sorted-completions-table as much as possible, and for
filename completion, it caches the list of files in the base directory
(file-name-directory).
https://github.com/ShuguangSun/emacsimprovement/tree/master/bug%2329833









On Sun, Dec 24, 2017 at 4:58 PM, Shuguang Sun <shuguang@gmail.com> wrote:

> Hi,
>
> The icomplete re-build the completion table 'completion-all-sorted-completions'
> after each key press. However, I think it should keep the
> 'completion-all-sorted-completions' builded at beging and re-use it
> afterwise.
>
> At least in Windows, GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32) of
> 2017-12-09.
>
> How to repeat it:
> 1: emacs -q
> 2: icomplete-mode (we can't find anything wired unless we call
> dired-do-copy on a network-mapped remote file under a slow network)
> 3: modify function icomplete-exhibit to log as below:
>     insert '(print completion-all-sorted-completions)' between
> '(save-excursion  (goto-char (point-max))' and '(if (and (or
> icomplete-show-matches-on-no-input', and C-M-x.
>     Then it will print 'nil' after each key press which means
> 'completion-all-sorted-completions' is empty.
> 4. modify function icomplete-completions to log as below:
>     insert '(print completion-all-sorted-completions)' at the begining of
> the function body, prior to "(let* ((minibuffer-completion-table
> candidates)'.
>     Then it will print 'nil' after each key press which means
> 'completion-all-sorted-completions' is empty.
>
> Thereby, it has to call "(comps (completion-all-sorted-completions
> (icomplete--field-beg) (icomplete--field-end)))' in function
> icomplete-completions to re-build the completiong table after each key
> press.
>
> Thanks *Stefan Monnier *to point out it should be a bug in the help
> maillist.
>
> By the way, '(sequencep (icomplete--completion-table))' in function
> icomplete-exhibit always returns 'nil', and the icomplete-delay-completions-threshold
> actually has no effect.
> (print (icomplete--completion-table)) just returns the table name
> (function to generate the table), but not the content of the table.
>
> By the way again, if call dired-do-copy or dired-do-rename,
> icomplete-max-delay-chars counts the whole path of the file because, the
> path has been put to the minibuffer automatically. This may not a bug,
> however, I think it should be documented.
>
>
> Best Regards,
> Shuguang Sun
>