How about:
Don't sort the list, or consider "lazy sorting" only the portion of the
list that's going to be displayed. (I'd suggest using an incremental
Quicksort, which can yield a sorted sublist in almost linear time. (I
started working on this for my zcomp module until I realised it was already
On Thu, Jan 11, 2024, 23:21 Chet Ramey wrote:
> On 1/10/24 12:28 AM, Eric Wong wrote:
> > Hi, I noticed bash struggles with gigantic completion lists
> > (100k items of ~70 chars each)
> >
> > It's reproducible with both LANG+LC_ALL set to en_US.UTF-8 and C,
> > so it's not just locales slowing t
On 1/10/24 12:28 AM, Eric Wong wrote:
Hi, I noticed bash struggles with gigantic completion lists
(100k items of ~70 chars each)
It's reproducible with both LANG+LC_ALL set to en_US.UTF-8 and C,
so it's not just locales slowing things down.
This happens on the up-to-date `devel' branch
(commit
"Dale R. Worley" wrote:
> A priori, it isn't surprising. But the question becomes "What
> algorithmic improvement to bash would make this work faster?" and then
> "Who will write this code?"
I'll try to take a look at it in a few months if I run out of
things to do and nobody beats me to it. I'
Eric Wong writes:
> Hi, I noticed bash struggles with gigantic completion lists
> (100k items of ~70 chars each)
A priori, it isn't surprising. But the question becomes "What
algorithmic improvement to bash would make this work faster?" and then
"Who will write this code?"
Dale
Hi, I noticed bash struggles with gigantic completion lists
(100k items of ~70 chars each)
It's reproducible with both LANG+LC_ALL set to en_US.UTF-8 and C,
so it's not just locales slowing things down.
This happens on the up-to-date `devel' branch
(commit 584a2b4c9e11bd713030916d9d832602891733d7
