GNU bug report logs - #49127
Performance degradation in encode_coding_object

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: victor.nawothnig <at> icloud.com
Cc: 49127 <at> debbugs.gnu.org
Subject: bug#49127: Performance degradation in encode_coding_object
Date: Thu, 24 Jun 2021 19:49:41 +0300

Ping!  Could you please respond to my requests below?  I'd like to
make some progress with this bug report.

> Date: Sun, 20 Jun 2021 12:04:59 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 49127 <at> debbugs.gnu.org
> 
> > Date: Sun, 20 Jun 2021 08:30:24 +0200
> > From:  Victor Nawothnig via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> > 
> > With gprof/prof_events I have nailed the problem to be encode_coding_object looping over all markers. In degenerate cases this list can contain millions of markers. Traversing this list is particularly slow because of the indirection being a singly linked list. Based on the fact that a GC remedies this, I’m assuming this list contains mostly  unreachable markers. When stepping through encode_coding_object with GDB after a GC this list of markers shrinks to small double digit numbers from millions.
> > 
> > The source of these markers appears to be looking-at in the font locking code of haskell-mode, this assumption is based on the fact that commenting out the uses of looking-at in haskell-mode prevents the accumulation of markers and thus the slowdown.
> 
> Do you understand why using looking-at causes creation of markers?  If
> so, can you show the details of why this happens?
> 
> > One contributing factor to all of this, is that for lsp-mode to perform adequately, one needs a relatively high gc-cons-threshold, which means GCs that would clean up the markers run more rarely, leading to higher accumulation of markers over time.
> 
> Yes, playing with GC threshold is usually a bad idea, but it is hard
> to explain to people why, and they keep doing that, to their cost.
> 
> > This problem only triggers in terminal frames, but not in GUI frames. Setting GDB breakpoints suggests that the GUI frame never even calls into encode_coding_object.
> 
> Can you should a backtrace from the call to encode_coding_object,
> including the Lisp backtrace (via the "xbacktrace" command)?
> 
> > So far I’m torn on whether this is a bug in the haskell-mode font locking code or in Emacs. What do you think?
> 
> Let's revisit this question after we have all the data I requested
> above, okay?
> 
> Thanks.
> 
> 
> 
> 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.