[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#49127: Performance degradation in encode_coding_object
From: |
Eli Zaretskii |
Subject: |
bug#49127: Performance degradation in encode_coding_object |
Date: |
Sun, 15 Aug 2021 18:07:23 +0300 |
Ping! Ping! Ping! Please respond!
> Date: Sun, 25 Jul 2021 10:10:40 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 49127@debbugs.gnu.org
>
> Ping! Ping! Please respond, so we could take care of this issue.
>
> To recap: I would like to have a backtrace from the call to
> encode_coding_object, including the Lisp backtrace (via the
> "xbacktrace" command), so that we could see how this performance issue
> happens.
>
> TIA
>
> > Date: Thu, 24 Jun 2021 19:49:41 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 49127@debbugs.gnu.org
> >
> > 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@gnu.org>
> > > Cc: 49127@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@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.
- bug#49127: Performance degradation in encode_coding_object,
Eli Zaretskii <=
- bug#49127: Performance degradation in encode_coding_object, Eli Zaretskii, 2021/08/16
- bug#49127: Performance degradation in encode_coding_object, Mattias Engdegård, 2021/08/16
- bug#49127: Performance degradation in encode_coding_object, Eli Zaretskii, 2021/08/16
- bug#49127: Performance degradation in encode_coding_object, Mattias Engdegård, 2021/08/16
- bug#49127: Performance degradation in encode_coding_object, Eli Zaretskii, 2021/08/17
- bug#49127: Performance degradation in encode_coding_object, Mattias Engdegård, 2021/08/17
- bug#49127: Performance degradation in encode_coding_object, Eli Zaretskii, 2021/08/17
- bug#49127: Performance degradation in encode_coding_object, Mattias Engdegård, 2021/08/17
- bug#49127: Performance degradation in encode_coding_object, Eli Zaretskii, 2021/08/17