GNU bug report logs - #38407
27.0.50; infinite loop with display of large file without newlines

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: pieter <at> vanoostrum.org, 38407 <at> debbugs.gnu.org
Subject: Re: bug#38407: 27.0.50; infinite loop with display of large file
 without newlines
Date: Sun, 01 Dec 2019 19:45:11 +0200

> Cc: Eli Zaretskii <eliz <at> gnu.org>, 38407 <at> debbugs.gnu.org
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Date: Sun, 1 Dec 2019 23:37:46 +1300
> 
> On 1/12/19 8:23 PM, Pieter van Oostrum wrote:
> > Here it is, compressed. I am loading the uncompressed file,
> > of course.
> 
> Without bidi-inhibit-bpa, visual-line-mode is certainly brutal
> with this file (I've been waiting several minutes for Emacs 27
> to respond to `end-of-buffer').

8.5 minutes here, with an unoptimized build.

> However, for me, bidi-inhibit-bpa comprehensively deals to that.

Down to 1 min here.

One other observation is that the first time you do that in a session
after visiting the file, it takes much longer than the subsequent
times.  Here, the second M-> takes 5 min with bidi-inhibit-bpa nil and
just 17 sec with it non-nil.

So I think some of this time is spent doing something we do once,
maybe loading fonts or something (this file has a lot of different
scripts).

It would be interesting to run perf and compare its output with
bidi-inhibit-bpa nil and non-nil.  Maybe the performance hit due to
visual-line-mode is because of some code that could be optimized, or
maybe (gasp!) even a bug.  The difference between the first and
subsequent moves is also interesting to time.

I don't have access to a GUI system where I can run perf, so could
someone please do these measurements and post the resulting profiles?

Previous Next

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