GNU bug report logs - #15841
Display bugs with cache-long-lines non-nil

Previous Next

Full log

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15841 <at> debbugs.gnu.org, nbtrap <at> nbtrap.com
Subject: Re: bug#15841: Display bugs with cache-long-lines non-nil
Date: Thu, 14 Nov 2013 00:45:17 +0100

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

> > From: Michael Heerdegen <michael_heerdegen <at> web.de>
> > Cc: 15841 <at> debbugs.gnu.org,  nbtrap <at> nbtrap.com
> > Date: Mon, 11 Nov 2013 04:39:56 +0100
> > 
> > The culprit was my own code: it placed myriads of invisible overlays
> > with no properties into the buffer.  Under these extreme circumstances,
> > `line-number-at-pos' indeed gets extremely slow at the end of my 10000
> > lines buffer: one invocation needs over a second.  I saw that with elp
> > as well as with profiler.  Setting `cache-long-scans' to nil (or
> > removing the overlays) cures this.
>
> Can you show some simple enough code that puts so many overlays, and
> has this effect?  It sounds like some optimization is in order.

Sorry, I did not find an easy test case.  I tried to simplify the
essence of what my code does, but the effect didn't occur.  Seems that
lots of different things must come together to provoke this symptom.
Given the fact that my code was really broken, I don't think it's worth
the time to follow this up.  It would cost me many hours to compile some
test code for emacs -Q.  Or do you think it would be worth it?  If you
think it could be very important, I would do it, but it would be very
time intensive.  My code works well now with `cache-long-scans' t after
the right fixes, btw.


Regards,

Michael.

Previous Next

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