bug#48841: fido-mode is slower than ido-mode with similar settings

[Dmitry Gutov]

On 18.06.2021 00:21, João Távora wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> > > > I disagree it's a simpler technique, but it would indeed be a simpler
> > > > change, based on the current implementation.
> > > simpler means simpler in my book :-)
> >
> > One is simpler diff, another is simpler resulting code. Both have
> > their upsides.
>
> Oh, you meant the The Big Redesign?  I'm a fan of that too, not only
> here but constantly, everywhere...  That indeed means simpler resulting
> code in abstract.  Problem is that also means different resulting code
> to different people.  But is definitely doable.

I meant a particular change (not modifying the strings at all in 
advance) which would be bigger and indeed might better fit The Big Redesign.

> > > > But I don't mind it myself, and happy to update Company. Either way
> > > > it's a step forward.
> > > If Company and fido-mode and a couple more outside the core/Elpa are
> > > all
> > > that's needed, it's probably warranted.  But there are so many frontends
> > > right now, I don't know...  We'd need some "opt into the optimization",
> > > I think."
> >
> > Since all other users are third-party (and thus have short release
> > cycles), it shouldn't be too much of a problem. Some highlighting code
> > would start to fail, but probably without disastrous results. And then
> > people will issue updates to look for some new property when the old
> > expected ones are all missing.
>
> OK.  I can live with that rationale.  So what are the places to touch
> that "we" control?
>
> - icomplete.el? for fido-mode & friends
> - minibuffer.el, for the *Completions* buffer
> - company.el
> - Any notable others?

corfu, consult, etc? Probably Ivy too. All of these are in GNU ELPA.

BTW, I think Daniel had some ideas about applying the face property 
lazily as well. I can't find the particular discussion now, but perhaps 
he can add to this discussion as well.

> > >      ;; with copy
> > >      (2.869362171 6 2.3882547280000495)
> > >      (2.909661303 6 2.4209153659999743)
> > >      (2.845522439 6 2.3638140250000106)
> > >           ;; without copy.  Huge speedup.
> > >      (0.79817337 1 0.4526993239999797)
> > >      (0.8231736510000001 1 0.4752496449999626)
> > >      (0.719004478 1 0.4016016420000028)
> >
> > Even better.
> >
> > My current session has 37559 symbols, so it's somewhere in the middle.
>
> Yes, this is a big performance bottleneck.  But i wonder if tweaking GC
> parameter would help here.  I know nothing of Emacs GC parameters.

I think the current understanding that by raising gc-cons-threshold we 
exchange the number of GC pauses for larger latencies. I suppose one 
could tune that value to a particular workload such that the 4 GCs in a 
row that I had will turn into just one (and thus save on re-scanning the 
heap 3 times), but data sets change.