Executing code interactively in Quarto is often extremely slow

[mattansb]

Running code chunks with the little play button(s) / single lines with ctrl + enter can be extremely slow - here is a code chunk that took more than 10 seconds (!) to run the other day:

```{r}
1
```

Rendering (in what ever way) does not suffer this sluggishness.

Now I say it "can" be very slow because sometimes everything runs as I would normally expect, so I can't seem to reproduce this on demand :/ and I have no idea how to try and profile this...

---

My setup: Latest Positron (2026.10.0), latest Quarto plugin (1.138.0), and Quarto (1.10.19), with R 4.6.1, on Windows.

---

Okay, that's all I can say with certainty. Here are some additional subjective thoughts:

• It seems like this often happens when (or after) the code/chunk has some output to display - a standard print output, but also a plot or table (e.g., with {gt})
• If I recall correctly, this started happening when Positron switched to kernels for Quarto docs (before code was just running from the main session/s, right?) and has been progressively getting worse.

Any ideas? Tips?

[juliasilge]

Thanks for the detailed report, and especially for the note about when this started. To help narrow it down, could you answer a few questions?

The most important one first is whether you have quarto.inlineOutput.enabled set to true (or the older positron.quarto.inlineOutput.enabled)? In other words, do chunk outputs appear inline in the editor, or in the Console and Plots panes? When inline output is on, Quarto docs execute through a per-document kernel, which is a different code path from the console session, so your answer changes where we look.

1. Is the slowness limited to .qmd files, or does it also happen in a plain .R script when you run a line with Ctrl+Enter?
2. When a chunk is slow, is the same expression also slow if you type it directly into the Console?
3. During a hang, is the R process busy in Task Manager, or idle? That tells us whether the delay is in R itself or in communication/rendering.
4. Your example chunk (1) still prints output ([1] 1). Have you seen the slowness with statements that produce no output at all, e.g. x <- 1?
5. Roughly how large is the document when it happens, and about how many outputs (especially plots or HTML tables like gt) are already rendered inline?
6. Does restarting the R session make it fast again for a while?

For logs, next time it happens:

• Grab the R 4.6.1: Kernel and R 4.6.1: Console channels from the Output panel (plus Quarto, if present) and look for where the time gap sits.
• Even better, a trace-level repro: Ctrl+Shift+P > Developer: Set Log Level > Trace, reproduce the slowness, then check those same channels.
• Also check Developer: Toggle Developer Tools for errors during a slow run.

One Windows-specific thought might be that antivirus or Defender real-time scanning on the project folder or R's temp directory can add intermittent latency to the local TCP connections that Jupyter kernels use on Windows, so it's worth checking whether security software is active there.

One thing we don't need to worry about is that quarto render runs fast, because that is expected regardless. Rendering happens in a separate, non-interactive R process and never touches the kernel or inline output path, so that difference isn't diagnostic.

[mattansb]

Hey Julia - thanks for responding so fast!

Yes I do have quarto.inlineOutput.enabled enabled and am seeing things run in a separate kernel instance than the console session. I'll try and maybe toggle this off and see if the problem persists.

I also seem to have quarto.useBundledQuartoInPositron toggled off - should I change that?

---

1. This does not happen in regular .R files

2. I can't really check that since switching to the console "loses" the connection to the session run in the doc's kernel.

<3. I can't seem to get it to hang right now when I run it to check. I'll post back here next time it happens>

4. See previous point, but I think it is related somehow to printing outputs - like I recall this happening more or more often with chunks that have outputs or after running chunks with outputs. As I said, this behavior is highly variable and I'm not sure how to trigger it on purpose...

5. The latest case is rather short, a Quarto file of about 500~ lines, with a total of 21 chunks (8 tbl- chunks with {gt} and 4 fig- chunks with {ggplot2})

6. No. In fact by the time it reaches the point that I can't stand it anymore, I often can't restart the kernel and I have to close Positron completely.

---

I'm not seeing an R 4.6.1: Console - am I looking in the right place?

[juliasilge]

This is all really helpful! Your answers point strongly at the inline output path rather than R itself: plain .R files execute through the same kernel and transport, so if those are fast, the difference is likely in how results get rendered in the editor. And the fact that restarting the R session doesn't help, while quitting Positron entirely does, suggests something is accumulating on the workbench side over the life of the window. That's a useful clue. (Also, no worries on question 2; the console session is indeed separate from the doc's kernel, and your answer to question 1 already told us what we needed there.)

A few follow-ups:

1. Yes, please do try setting quarto.inlineOutput.enabled to false for a few days. With it off, chunks route to the console session instead, so if the slowness disappears, that confirms where we should dig.
2. No need to change quarto.useBundledQuartoInPositron. It only controls which Quarto CLI is used for quarto render, not interactive execution.
3. Apologies, I gave you the wrong Output channel names. The ones to check are R Kernel and R Supervisor (plus Kernel Supervisor if those don't show where the time goes).
4. Next time things degrade, could you open Developer: Open Process Explorer from the Command Palette (Ctrl+Shift+P) and see which process is consuming memory and CPU? If the Positron window or extension host process looks bloated while R is normal, that would support the rendering-side theory.
5. If you're up for one more experiment, could you work for a while in a document of similar length but with the tbl- chunks removed, or with plain data frame printing instead of {gt} for a while? HTML outputs like gt tables are the heaviest thing inline output renders, so this would tell us whether those specifically are the trigger.

And whenever it hangs again, trace-level logs from the channels above (Developer: Set Log Level > Trace, reproduce, then check R Kernel and R Supervisor) would still be valuable.

[mattansb]

Thanks Julia - I haven't had a chance yet to see any effect of setting "quarto.inlineOutput.enabled": false, but I think my next project will make extensive use of Quarto, so I'll keep you poster over the coming weeks.

Thanks again!