bug#44610: 27.1; Keyboard Macro Performance Problem

[Eli Zaretskii]

> From: Robert Thorpe <rt@robertthorpeconsulting.com>
> Cc: 44610@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.