GNU bug report logs - #16830
[Bug] 24.3.50; massive slow down in forward-line

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: 16830-done <at> debbugs.gnu.org
Subject: Re: bug#16830: [Bug] 24.3.50; massive slow down in forward-line
Date: Sun, 22 Jun 2014 19:50:52 +0300

> Date: Mon, 17 Mar 2014 18:39:33 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 16830 <at> debbugs.gnu.org
> 
> > Date: Mon, 17 Mar 2014 19:05:27 +0400
> > From: Dmitry Antipov <antipov <at> dev.rtsoft.ru>
> > CC: 16830 <at> debbugs.gnu.org
> > 
> > On 03/10/2014 10:58 PM, Eli Zaretskii wrote:
> > 
> > > It would be nice to be able to turn the cache on and off dynamically,
> > > depending on the actual line length of the buffer.  I tried to
> > > implement this, but my naive implementation didn't work well, because
> > > sampling of the lines tends to be extremely un-representative.  If
> > > someone can come up with a smarter implementation, please show it.
> > 
> > What if we just maintain the '\n' counter per each buffer text?
> 
> How would you know how many newlines are there in the buffer?
> Counting them is an overhead in itself that we currently avoid (see
> line-number-display-limit).
> 
> But anyway, feel free to implement something and test it.  As I've
> written above, I tried (for admittedly short time), but didn't get
> good results.

No further comments, so I'm closing this bug, as I see no further
place for improving the performance of the cache.

Previous Next

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