GNU bug report logs - #49127
Performance degradation in encode_coding_object

Previous Next

Package: emacs;

Reported by: Victor Nawothnig <victor.nawothnig <at> icloud.com>

Date: Sun, 20 Jun 2021 08:19:03 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #20 received at 49127 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias EngdegÄrd <mattiase <at> acm.org>
Cc: 49127 <at> debbugs.gnu.org, victor.nawothnig <at> icloud.com
Subject: Re: bug#49127: Performance degradation in encode_coding_object
Date: Mon, 16 Aug 2021 20:43:20 +0300
> From: Mattias EngdegÄrd <mattiase <at> acm.org>
> Date: Mon, 16 Aug 2021 19:32:46 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 49127 <at> debbugs.gnu.org
> 
> It looks very much like haskell-mode is producing way too many markers, and that should be easily fixed (I wrote a tentative pull request). However, the code in encode_coding_object appears broken. Look at the first loop in that function:
> 
>   if (EQ (src_object, dst_object))
>     {
>       struct Lisp_Marker *tail;
> 
>       for (tail = BUF_MARKERS (current_buffer); tail; tail = tail->next)
> 	{
> 	  tail->need_adjustment
> 	    = tail->charpos == (tail->insertion_type ? from : to);
> 	  need_marker_adjustment |= tail->need_adjustment;
> 	}
>     }
> 
> I don't know how this could ever work. We loop through the markers in the current buffer?

Yes.  Why do you think this loop is broken?

> It is called from term.c with src_object and dst_object both being Qnil; no buffer is involved at all. At the very least the outer condition should have an "&& BUFFERP (dst_object)" added, and the loop should run through the markers of XBUFFER (dst_object) instead of current_buffer, no?
> 
> `decode_coding_object` seem to get these things right but I only took a superficial look. It's probably copy-paste errors.

It isn't a copy/paste, I think it's a simple omission.

But if you look up-thread, you will see that I asked for xbacktrace
results from the OP, to make sure I completely understand the reasons
for the performance problem.  I never got any responses for that.  So
if you can produce the Lisp backtraces in that case, and later test a
fix, I'm quite sure I know how to fix this problem.  TIA.




This bug report was last modified 3 years and 274 days ago.

Previous Next


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