GNU bug report logs - #44610
27.1; Keyboard Macro Performance Problem

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Thorpe <rt <at> robertthorpeconsulting.com>
Cc: 44610 <at> debbugs.gnu.org, bugs <at> gnu.support
Subject: bug#44610: 27.1; Keyboard Macro Performance Problem
Date: Mon, 16 Nov 2020 18:23:08 +0200

> From: Robert Thorpe <rt <at> robertthorpeconsulting.com>
> Cc: 44610 <at> debbugs.gnu.org
> Date: Sun, 15 Nov 2020 23:44:32 +0000
> 
> > I suggest to produce and present a profile of this.  Invoke this macro
> > after "M-x profiler-start RET RET", then "M-x profiler-report RET",
> > expand the profile fully by "C-u RET" on the top line, and post the
> > result here.  That should give some clues.
> 
> Here is the report.  I did it in Python-mode using Emacs -Q on Emacs
> 27.1.  My machine is a Dell 14-3480.  The profile I've got seems to be a
> bit different to the one Jean Louis got.
> 
> It is a little faster using Emacs -Q than my own init, but it's
> still fairly slow.
> 
> I notice that in my report the GC is taking about 39% of runtime.  I'm
> not sure why it's taking longer than in Jen Louis' report.
> 
> It's faster if I use forward-line rather than pressing C-n.  Also the
> report looks very different.  I've added that at the end.  The first
> report is the one using C-n.

Thanks.  I think the conclusion is quite clear:

> - command-execute                                                3499  60%
>  - call-interactively                                            3499  60%
>   - funcall-interactively                                        3480  59%
>    - kmacro-end-or-call-macro                                    3474  59%
>     - kmacro-call-macro                                          3474  59%
>      - call-last-kbd-macro                                       3464  59%
>       - command-execute                                          3419  58%
>        - call-interactively                                      3417  58%
>         - funcall-interactively                                  3417  58%
>          - next-line                                             3345  57%
>           - line-move                                            3345  57%
>            - line-move-visual                                    3339  57%
>             - vertical-motion                                    3132  53%
>              - jit-lock-function                                 3132  53%
>               - jit-lock-fontify-now                             3131  53%
>                - jit-lock--run-functions                         3112  53%
>                 - run-hook-wrapped                               3112  53%
>                  - #<compiled 0x15629e8957cd>                    3111  53%
>                   - font-lock-fontify-region                     3111  53%
>                    - font-lock-default-fontify-region               3111  53%
>                     - font-lock-fontify-syntactically-region               3082  53%
>                      - python-font-lock-syntactic-face-function               3063  52%
>                       - python-info-docstring-p                  3055  52%
>                        - python-nav-backward-sexp                3016  51%
>                         - python-nav-forward-sexp                3007  51%
>                          - python-nav--forward-sexp               2968  51%
>                           - python-info-beginning-of-block-p               2005  34%
>                            - python-info-beginning-of-statement-p               1670  28%
>                             - python-nav-beginning-of-statement               1644  28%
>                              - syntax-ppss                       1392  23%
>                                 #<compiled 0x15629eb1977d>                  1   0%

The culprit is indeed fontifications, and specifically the code in
python-nav--forward-sexp and its subroutines.  So this is where
optimizations or simplifications will yield the greatest speedup.

Previous Next

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