Re: Emacs graphical frontends / responsiveness

[Jordan Ellis Coppard]

On 21/10/2024 4:39 am, Suhail Singh wrote:
> This is odd.  Starting from emacs -Q, when does this issue manifest
> itself?  Specifically, is this the case when typing in a new text buffer
> (pointing to a local file, and not over the network) in
> fundamental-mode?  If not, what's the minimal reproducible example
> starting from emacs -Q?  If you have already submitted a bug-report with
> those details, could you please post the reference?

Between now and then I have stopped using hotfuzz 
(https://github.com/axelf4/hotfuzz) which implements a completion style 
similar to Emacs' flex but as a dynamic module.

I don't know if it's something to do with their code, or Emacs NS (as 
they do report some benchmarks showing hotfuzz is faster) but it turns 
out /that/ was the reason for major slowdowns while typing with 
completion. Orderless and Emacs' built-in flex and basic are fast enough 
so this was premature optimisation by me perhaps; I was even basing my 
memory off of a configuration without native compilation too.

So: no hotfuzz and it's fast, some teeny tiny slowdown in huge lists but 
nothing like before.

I think typing in the buffer was due to diff-hl in combination with some 
(apparent) bug whereby fringes and margins were always redrawn on Emacs 
NS and were redrawn using expensive bezier curves. I believe Ben Simms 
found this out, and I've been using his patches 
(https://github.com/emacs-mirror/emacs/compare/master...simmsb:better-emacs-ns-graphics:master) 
since shortly after my initial email with no slowdown at all.

That's not an apples to apples comparison; but I'm already behind on 
some work I should be doing and didn't have enough time to perform a 
proper comparison.

I believe Ben's patches might land in master soon so once they are in I 
could try with a build from master, without additional patches, and see 
if lag occurs again for a more up-to-date baseline of any potential problem.