GNU bug report logs - #39598
26.3; Emacs is extremely unresponsive on a trivial python file

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ivan Oreshnikov <oreshnikov.ivan <at> gmail.com>
Cc: 39598 <at> debbugs.gnu.org
Subject: bug#39598: 26.3; Emacs is extremely unresponsive on a trivial python file
Date: Sat, 15 Feb 2020 10:05:27 +0200

> From: Ivan Oreshnikov <oreshnikov.ivan <at> gmail.com>
> Date: Fri, 14 Feb 2020 17:31:48 +0100
> Cc: 39598 <at> 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?

Previous Next

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