bug#2445: 23.0.90; file name completion GCs a lot

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> When I type C-x C-f xmail/foox TAB, where xmail contains 800 files
> and none of them starts with foox, it takes a few seconds (including
> 3 GCs) before telling me it can't be found.
> Here's output from xbacktrace:

>     "file-name-completion" (0x7fbe23e4)
>     "completion--file-name-table" (0x7fbe26c4)
>     "complete-with-action" (0x7fbe29a4)
>     0x87978c PVEC_COMPILED
>     "byte-code" (0x7fbe2f14)
>     "completion--some" (0x7fbe33b4)
>     0x8797dc PVEC_COMPILED
>     "apply" (0x7fbe3710)
>     "read-file-name-internal" (0x7fbe38f4)
>     "try-completion" (0x7fbe3a74)
>     "completion-pcm--find-all-completions" (0x7fbe3f2c)
>     "completion-pcm-try-completion" (0x7fbe4214)
>     0x879d04 PVEC_COMPILED
>     "byte-code" (0x7fbe4784)
>     "completion--some" (0x7fbe4c24)
>     "completion-try-completion" (0x7fbe4f04)
>     "completion--do-completion" (0x7fbe51f4)
>     "minibuffer-complete" (0x7fbe550c)
>     "call-interactively" (0x7fbe5764)
>     "completing-read" (0x7fbe5ebc)
>     "read-file-name" (0x7fbe61ac)
>     "find-file-read-args" (0x7fbe648c)
>     "byte-code" (0x7fbe671c)
>     "call-interactively" (0x7fbe69c4)

> I think that is because of the partial completion feature
> that is now enabled by default and was not before.

It may be, indeed.  But there's no good reason why it should be much
slower in such a circumstance.  A factor of 2 slowdown should be
expected, but not much more than that since the "xmail/foox" pattern
doesn't offer much opportunity for partial completion.
So it sounds more like an implementation inefficiency somewhere.


        Stefan