bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
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 <address@hidden>
> Date: Fri, 14 Feb 2020 17:31:48 +0100
> Cc: address@hidden
> 
> 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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]