GNU bug report logs - #31888
27.0.50; Segmentation fault in replace-buffer-contents

Previous Next

Full log

Message #16 received at 31888-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: k.michal <at> zoho.com
Cc: 31888-done <at> debbugs.gnu.org
Subject: Re: bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents
Date: Sat, 23 Jun 2018 14:15:23 +0300

> Date: Fri, 22 Jun 2018 16:03:02 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 31888 <at> debbugs.gnu.org
> 
> The command is still too slow (takes about 2.5 min for the above use
> case in my unoptimized build, about 30 sec of which is spent in
> compareseq).  I will try to look into speeding it up.

I could find only a minor speedup (about 10%), by slightly changing
buffer_chars_equal per suggestion in another bug report.

In this particular case, replacing the contents of dispnew.c with that
of contents.c takes 2018 deletions and 2781 insertions, each one of
these operations takes about 20 msec in the unoptimized build where I
timed them; the call to compareseq takes another 26 sec (expect the
times to be lower by a factor of 3 in an optimized build).  My
conclusion from various attempts to speed up the code was that most of
this time is taken by making small changes to buffer text, which
involves moving the gap, which in turn requires shuffling of buffer
text to and fro.  I don't see how can we speed that up if we stay with
the current idea of the function, and want to preserve text properties
and overlays as much as possible.

So I ended up inserting a few calls to maybe_quit into the inner loops
of the function, to allow users bail out of lengthy execution, and
warning about the potential slowness in the doc string.

I'm closing this bug; if someone has ideas for how to speed up the
function significantly, please reopen, or file a new bug.

Previous Next

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