GNU bug report logs - #64391
30.0.50; buffer narrowing slowdown regression in emacs 29

Previous Next

Packages: emacs, gnus;

Reported by: Andrew Cohen <acohen <at> ust.hk>

Date: Sat, 1 Jul 2023 00:21:02 UTC

Severity: normal

Found in version 30.0.50

Full log


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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acohen <at> ust.hk, 64391 <at> debbugs.gnu.org, mattias.engdegard <at> gmail.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#64391: buffer narrowing slowdown regression in emacs 29
Date: Thu, 06 Jul 2023 18:45:50 +0000
>> I pushed a proposed change to the scratch/bug64391 branch.
>>
>> It contains three commits:
>>
>> - b741dc7fcd which is the minimal possible commit to fix this bug
>>
>> - 01fb898420 which moves a few statements from the callee 
>> (internal--label-restriction) to its only caller 
>> (internal--labeled-narrow-to-region), and simplifies the code 
>> accordingly
>>
>> - c52ade305e which is optional, and makes the symmetrical change for 
>> the widening case
>>
>> Eli and Mattias, could you perhaps have a look?
>
> How are those different from what Mattias proposed?  Is this a 
> completely different set of changes, or is it what Mattias suggested, 
> just in several separate parts?
>

It resembles what Mattias proposed of course (remove the negative effect 
of setting a buffer-local variable in all calls to narrow-to-region, and 
limit it to case when labeled narrowing is used), but it's nonetheless 
different.  The essential change is isolated in the first commit, and in 
the second commit, instead of moving the body of Fnarrow_to_region to 
another function with an additional (third) argument, I use another 
separate function which calls Fnarrow_to_region.  I believe the result is 
clearer.

>
> If these are different, did you time the results in the use case(s) 
> where the slow-down was detected and reported, and compared the two 
> proposals performance-wise?
>

Yes, there is no difference, performance-wise:

- with Mattias' patch:

Modify after narrowing:  0.114 s elapsed, 0 GCs, 0.000 s GC, 0.114 s non-GC
Modify before narrowing: 0.103 s elapsed, 0 GCs, 0.000 s GC, 0.103 s non-GC

- with the code in scratch/bug64391:

Modify after narrowing:  0.109 s elapsed, 0 GCs, 0.000 s GC, 0.109 s non-GC
Modify before narrowing: 0.102 s elapsed, 0 GCs, 0.000 s GC, 0.102 s non-GC

(The small differences are not meaningful, other runs show different 
values in the same order of magnitude.)





This bug report was last modified 1 year and 342 days ago.

Previous Next


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