GNU bug report logs - #26952
25.2; repeated buffer insertion (e.g. yank-rectangle) consumes excessive memory (4GB+ for 90MB of text)

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: jwiegley <at> gmail.com, eggert <at> cs.ucla.edu, npostavs <at> users.sourceforge.net, 26952 <at> debbugs.gnu.org
Subject: bug#26952: 25.1; loops eating all memory while yanking big rectangle
Date: Sat, 27 May 2017 10:42:46 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  jwiegley <at> gmail.com,  26952 <at> debbugs.gnu.org,  npostavs <at> users.sourceforge.net
> Date: Fri, 26 May 2017 21:15:32 -0400
> 
> If a ~ six month testing process doesn't show up the fairly fundamental
> memory issues that cropped up in both 25.1 and 25.2 soon after release,
> then perhaps it isn't time well spent.

AFAIU, the problem was discovered by Francesco this late because he
only now upgraded from Emacs 22(!) to 25.2.

> Perhaps people would be better served by more frequent, smaller
> releases.

I don't think we know how to do this, either.  The experience of 25.1
and 25.2 shows that it might take a couple of weeks, sometimes more,
from the decision to make a tarball until it finally hits the download
site.  We need to have a much faster turnaround if we want to go your
way.

Another issue is that we will have to be more stringent in our
documentation requirements accompanying each change, if we basically
want to release development snapshots.

> I have the feeling (not backed up by any data) that pretest use is
> declining, with people just using master or releases. Perhaps
> switching things around so that releases come from master (and
> development happens on a branch) would help, but maybe not.

If development happens on a branch, my guess is people who currently
use master will switch to tracking that branch instead, and we are
back at the same problem.

Previous Next

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