-
-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Indentation very slow on 20230911.1653 #665
Comments
Thanks much for the report! Will see if I can repro, if so I'll try to bisect its cause. |
I can't repro any sort of slowness - I can indent my whole ns buffer with clojure-mode in an instant. Are you using something like electric-indent-mode, clojure-lsp, anything else that might query the indentation system? |
thanks for looking into this! electric-indent, yes |
Nice. IIRC you can If you do it enough times, you might perceive a common pattern. |
Here's a possible lead clojure-emacs/cider#3344 Apparently "electric / aggressive indentation modes" can query Would very much appreciate if you could verify a specific cause. |
Here's a benchmark you can run for discarding/confirming that lead:
It returns 0.00005400 for me (and it successfully finds a repl - please make sure of that) - seems fast enough to be repeatedly invoked. |
I think this is the right direction, because I think I just found a huge supporting clue of several parts:
|
Thanks! Could you please Expanding on that, Assuming a given If |
for
|
Good find! The profiling doesn't appear to capture I tried profiling it myself now but I can't get it to show up in the report. I'll be happy to optimize |
Hey @daveliepmann , regardless of the profiling, I went ahead and improved that function since it was evident that it could be optimized: I'd much appreciate if you can try it locally. If you use ELPA, one way is to download those two files, place them in |
Thanks, I really appreciate you chasing these leads. I got those two files downloaded and running and see no change. (I confirmed they were the running code with describe-mode and some jump-to-def, though I didn't see any .elc files to delete — not sure if that could be an issue?) I also noticed that the slowdown in the clojure-mode-but-no-CIDER-REPL only occurs when there's a cider-connect'd babashka REPL running elsewhere, not when I have a cider-jack-in'd-JVM-REPL running elsewhere with the following start-up command:
|
I see! What's the value of |
Also, a quick way to check if the new code is being used is |
0.028764 |
Before it was 0.09996, right? It's still a progress but still not quite right. For a comparable case (I have 1 repl around, and invoke Perhaps the As you point out:
...I don't know what it could be. A successful profiling session could help. Try indenting code while profiling, to trigger the slow code path? |
Thanks much! I've upgraded clojure-emacs/cider#3463. Before, even though nothing was 'broken', the cache wasn't being hit. Now it is. I have verified so with numbers: for a 'non-friendly' buffer, runtime has improved from 0.00251 to 0.0003. |
I updated to the latest from that PR and profiled again; results in cpu-profiler-report2. seemed marginally faster at best |
Thanks! I don't see a smoking gun. Could you please perform the following?
|
sure (lightly edited)
|
Thanks, interesting. What's the output of |
|
Thanks! Is this part ...That would mean that babashka is returning a nil classpath, which might have to do with the whole thing. In addition, please visit the bb repl and eval both of these individually (after having reproduced the issue one more time):
What does each expr return? |
Correct, that is as-is. I just elided the path on my machine.
|
Thanks. So, the process isn't holding any of the big objects to be cached. Maybe that's related to the nature of bb? Since it's an nrepl server I'd imagine it's a persistent process, but also bb is oriented towards one-off things (i.e., they run and complete very quickly) so maybe something is 'one-off' there? That would mean a bb repl is unable to cache anything. Does that ring a bell? |
I'm not qualified to answer for bb; maybe @borkdude knows? |
The exact question is whether cider's nrepl-server process that is backed by bb is a "true" persistent server, or contrariwise something that is spawned on demand for each request. Not sure if Michiel implemented that, but he might know! |
The server is persistent. |
This speeds up `(cider-current-repl)` performance in non-linked buffers from to 0.01s to 0.00098800s. Because `(cider-current-repl)` can be repeatedly invoked by e.g. `electric-indent-mode`, it makes a difference. Fixes clojure-emacs/clojure-mode#665
This speeds up `(cider-current-repl)` performance in non-linked buffers from to 0.01s to 0.00098800s. Because `(cider-current-repl)` can be repeatedly invoked by e.g. `electric-indent-mode`, it makes a difference. Fixes clojure-emacs/clojure-mode#665
As part of clojure-emacs/cider#3456 I just upgraded to clojure-mode-20230911.1653, which seems to have caused a tremendous performance regression around indenting forms.
Expected behavior
Indentation is fast enough not to interrupt flow
Actual behavior
A ~30-line
let
ordo
now takes just under 10 seconds to indent.A ~400-line buffer froze emacs for about a minute while indenting.
Carriage return at the end of a line has a sub-second but noticeable delay.
(Relatively consistent map literals seem significantly faster)
Steps to reproduce the problem
Write a large form then add a
do
orlet
or
given the following clojuredart form, add and remove the newline before
:get
:Environment & Version information
clojure-mode version
clojure-mode (version nil)
per #658clojure-mode-20230911.1653 by directory
Emacs version
GNU Emacs 28.2 (build 1, aarch64-apple-darwin22.1.0, Carbon Version 169 AppKit 2299) of 2022-12-10
Operating system
macOS ventura
The text was updated successfully, but these errors were encountered: