REPL is Slow and Performance Degrades as the Output Grows

[klauswuestefeld]

Evaluating this takes over 30 seconds to finish all output to the REPL:
(doseq [n (range 1000)]
(println n))

And performance degrades gradually as the output to .calva/output-window/output.calva-repl grows. :/

[bpringe]

Thanks for reporting, I can reproduce (though with a cleared output window, it's less than 30 seconds, but still way too high 😄), and in a terminal repl created with clj -r the output is virtually instant.. It's true that the output window lags far behind something like a terminal repl in speed of printing output.

I'm not sure this can be fixed with the current solution of using an editor / file buffer as the output window. This is because of the way VS Code applies edits to documents asynchronously. We have to queue them up and not start the next edit until the previous one has completed, otherwise issues may occur (I believe we implemented the queue due to an issue of not all output printing when multiple edits ran around the same time). Though, I'm not sure the queuing is the issue or if it's the way applyEdit and related code is implemented in VS Code.

I think #804 is also related. We'll need to apply some hammock time to figure out a good solution.

[bpringe]

I also happened to see this post on Reddit just today that was posted recently, that's related: https://www.reddit.com/r/Clojure/comments/krdihe/calva_with_reveal_repl/

[bpringe]

So, I tried this with Clover as well which uses a webview for its output window (which Calva used to use, and it came with a lot of maintenance problems trying to make it do what we wanted, especially with using it for input), and it still took maybe 1 or 2 seconds to show all output, and if I increased the number to 10000 it took maybe 5+ seconds, so while that implementation shows output much faster, it's still nowhere near the speed of terminal output.

I wonder if we can get the terminal speed in VS Code, at least for stdout like this, aside from results. Maybe @PEZ knows some options. I'm not suggesting a large change to the output window, but perhaps redirecting stdout to elsewhere would be something to try, or an option to give to the user via a setting (not seeing it there by default might pose more questions than its worth - "where's my output?").

[klauswuestefeld]

If there is a queue, can't we read all pending output events from the queue, concat them and apply them as a single batch to the output file? That would maybe make the console jumpy but at least it would not be absurdly slow. I wasted a few hours looking for performance issues in my code and it was the console :( I like the idea of having a setting to send stdout to the some standard VSCode output. Many people don't use the repl for input anyway, always using a scratch file instead.

…

On Tue, Jan 12, 2021 at 3:15 PM Brandon Ringe ***@***.***> wrote: So, I tried this with Clover as well which uses a webview for its output window (which Calva used to use, and it came with a lot of maintenance problems trying to make it do what we wanted, especially with using it for input), and it still took maybe 1 or 2 seconds to show all output, and if I increased the number to 10000 it took maybe 5+ seconds, so while that implementation shows output much faster, it's still nowhere near the speed of terminal output. I wonder if we can get the terminal speed in VS Code, at least for stdout like this, aside from results. Maybe @PEZ <https://github.com/PEZ> knows some options. I'm not suggesting a large change to the output window, but perhaps redirecting stdout to elsewhere would be something to try, or an option to give to the user via a setting (not seeing it there by default might pose more questions than its worth - "where's my output?"). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#942 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABMH5AY3JUOF3UDE5DNV5DSZSGTLANCNFSM4V57J4EA> .

[PEZ]

If there is a queue, can't we read all pending output events from the
queue, concat them and apply them as a single batch to the output file?

PR welcome! But it will be a bit tricky to know when to flush the queue. Pinting can be asynchronous and there is really no way of knowing when it is ”done”.

We'll look into an option for sending stdout to Calva says again. It wouldn't have helped you really, since you still need to figure out that the output window is behaving the way it does before you had reached for the option, but, yeah, it makes sense to have the option.

[klauswuestefeld]

When Calva opens the repl file it prints some helpful messages. One of these messages could be: "Output to this repl is slow. If you need faster output, use the following setting..." My use case is to run clojure.test/run-all-tests. If I disable the output they will run 60x faster :/

…

On Tue, Jan 12, 2021, 20:27 Peter Strömberg ***@***.***> wrote: If there is a queue, can't we read all pending output events from the queue, concat them and apply them as a single batch to the output file? PR welcome! But it will be a bit tricky to know when to flush the queue. Pinting can be asynchronous and there is really no way of knowing when it is ”done”. We'll look into an option for sending stdout to *Calva says* again. It wouldn't have helped you really, since you still need to figure out that the output window is behaving the way it does before you had reached for the option, but, yeah, it makes sense to have the option. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#942 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABMH5HUKBNMWKD2262RKZTSZTLG5ANCNFSM4V57J4EA> .

[bpringe]

I think a combination of a setting to send all stdout to a standard VS Code output channel (like the current "Calva says"), as well as documenting the slowness of printing stdout to the output/repl window, in the docs, as well as maybe in the welcome message of the output window as you say, would be the ideal solution here. You bring up a good point about run-all-tests, which makes this issue even more likely to be experienced than I thought.