bug#39598: 26.3; Emacs is extremely unresponsive on a trivial python file

[Eli Zaretskii <eliz@gnu.org>]

> From: Ivan Oreshnikov <oreshnikov.ivan@gmail.com>
> Date: Fri, 14 Feb 2020 17:31:48 +0100
> Cc: 39598@debbugs.gnu.org
> 
> Ok, here's the full expansion of the relevant part of the profiler report:

Looks like this part of python-nav--forward-sexp needs some
optimizations:

       (t
        ;; This part handles the lispy feel of
        ;; `python-nav-forward-sexp'.  Knowing everything about the
        ;; current context and the context of the next sexp tries to
        ;; follow the lisp sexp motion commands in a symmetric manner.
        (let* ((context
                (cond
                 ((python-info-beginning-of-block-p) 'block-start)
                 ((python-info-end-of-block-p) 'block-end)
                 ((python-info-beginning-of-statement-p) 'statement-start)
                 ((python-info-end-of-statement-p) 'statement-end)))
               (next-sexp-pos
                (save-excursion
                  (if safe
                      (python-nav--lisp-forward-sexp-safe dir)
                    (python-nav--lisp-forward-sexp dir))
                  (point)))
               (next-sexp-context
                (save-excursion
                  (goto-char next-sexp-pos)
                  (cond
                   ((python-info-beginning-of-block-p) 'block-start)
                   ((python-info-end-of-block-p) 'block-end)
                   ((python-info-beginning-of-statement-p) 'statement-start)
                   ((python-info-end-of-statement-p) 'statement-end)
                   ((python-info-statement-starts-block-p) 'starts-block)
                   ((python-info-statement-ends-block-p) 'ends-block)))))

For starters, it does a lot of processing to compute next-sexp-context
whose result is needed only in a couple of cases thereafter.  So maybe
avoiding some of that when not needed would help.

What is/are the real-life use case(s) where such long series of
strings causes slowdown?