Slow start of preview/render

[wiraki]

Description

I am rendering a single .qmd to html, and it is only using python and the jupyter engine. When I issue a render or preview command via CLI there is a 2-3 minutes delay until there is any stdout printed on the screen. Then follows the Starting python3 kernel...Done line which gets printed as is (there is no delay for the Done part).

Since there is nothing printed during the time before this gets printed, I am unsure how to interpret the delay. Is it still related to a slow start of the jupyter kernel?

I'd appreciate any pointers on what to check to figure this out!

[cscheid]

It shouldn't take this long - the jupyter kernel start takes a couple of seconds at most. What OS/quarto version are you running? Is it possible that you have security software that is attempting to scan the content of the quarto install every time its files are open?

[cscheid]

Quarto does a certain amount of searching in the directory for files (including _quarto.yml, etc). It's possible that your directories are so big that this is causing an issue.

The only characteristic of this directory is that it is rather large

How big are we talking about here? How many files, specifically?

[wiraki]

27039 directories, 287943 files, according to tree.

Total size is ~270GB.

I guess that explains it?

[wiraki]

I have done some needed clean-up and it has helped a lot!

[cscheid]

I'm not sure who's to blame here (us being inefficient or some standard library call in Deno). In any case, I'll open an enhancement request for this.

[wiraki]

Thank you!

I went down to 740 directories, 25399 files (but still 235G) and it has made a huge difference.

I had some old python environments locally stored there so lots of small files. I don't know if this information can be of assistance.

[kkasra12]

Hello,

I’m experiencing the same issue. My files are relatively few, but even when requesting a single file, I encounter the same problem. I’m using wsl with Quarto version 1.6.34. Running the command quarto preview file.qmd -v results in a significant delay of 2–3 minutes.

I also tested this on Windows, where it performs much faster. However, I face the following error:

[1/2] python\venv.qmd

Starting python3 kernel...Done

Executing 'venv.quarto_ipynb'
  Cell 1/12: ''...Done
  Cell 2/12: ''...Done
  Cell 3/12: ''...Done
  Cell 4/12: ''...Done
  Cell 5/12: ''...Done
  Cell 6/12: ''...Done
  Cell 7/12: ''...Done
  Cell 8/12: ''...Done
  Cell 9/12: ''...Done
  Cell 10/12: ''...Done
  Cell 11/12: ''...Done
  Cell 12/12: ''...Done


Access violation in generated code when reading 0xffffffffffffffff

 Attempting to reconstruct a stack trace...

   Frame        Code address
 * 0x9f65f8a9f0 0x7ff663e2e90e C:\Program Files\Quarto\bin\tools\pandoc.exe+0x2cae90e
 * 0x9f65f8a9f8 0x545c6c61636f4c5c
 * 0x9f65f8aa00 0x386c6c735c706d65
 * 0x9f65f8aa08 0x1da4500302e
 * 0x9f65f8aa10 0x1da476518b8
 * 0x9f65f8aa50 0x7ff665897ae3 C:\Program Files\Quarto\bin\tools\pandoc.exe+0x4717ae3
 * 0x9f65f8aab0 0x7ff6658880d4 C:\Program Files\Quarto\bin\tools\pandoc.exe+0x47080d4
 * 0x9f65f8abd0 0x7ff66588f54e C:\Program Files\Quarto\bin\tools\pandoc.exe+0x470f54e
 * 0x9f65f8ac10 0x7ff665888271 C:\Program Files\Quarto\bin\tools\pandoc.exe+0x4708271
 * 0x9f65f8ad80 0x7ff6658872d8 C:\Program Files\Quarto\bin\tools\pandoc.exe+0x47072d8
 * 0x9f65f8ade0 0x7ff6658887d5 C:\Program Files\Quarto\bin\tools\pandoc.exe+0x47087d5
 * 0x9f65f8ae40 0x7ff663dd784d C:\Program Files\Quarto\bin\tools\pandoc.exe+0x2c5784d
 * 0x9f65f8ae80 0x7ff661b75a11 C:\Program Files\Quarto\bin\tools\pandoc.exe+0x9f5a11
 * 0x9f65f8ae88 0x7ff66210b627 C:\Program Files\Quarto\bin\tools\pandoc.exe+0xf8b627
 * 0x9f65f8ae90 0x1da47a34fc0
 * 0x9f65f8ae98 0x7ef43cbf0718
 * 0x9f65f8aea0 0x7ef43dc165f0
 * 0x9f65f8aea8 0x3
 * 0x9f65f8aeb0 0x7ef43c799401
 * 0x9f65f8aeb8 0x3
 * 0x9f65f8aec0 0x1da47a2bfc0
 * 0x9f65f8af50 0x7ffc735328a6 C:\WINDOWS\SYSTEM32\ntdll.dll+0x128a6
 * 0x9f65f8afe0 0x7ffc73531f0d C:\WINDOWS\SYSTEM32\ntdll.dll+0x11f0d
 * 0x9f65f8b250 0x7ffc73530b00 C:\WINDOWS\SYSTEM32\ntdll.dll+0x10b00
 * 0x9f65f8b258 0x1da479bcb80
 * 0x9f65f8b260 0x1da45010000
 * 0x9f65f8b268 0x40
 * 0x9f65f8b270 0x20
 * 0x9f65f8b278 0x2
 * 0x9f65f8b280 0x1da45010000
 * 0x9f65f8b400 0x7ffc73555e0b C:\WINDOWS\SYSTEM32\ntdll.dll+0x35e0b
 * 0x9f65f8b590 0x7ffc735554f2 C:\WINDOWS\SYSTEM32\ntdll.dll+0x354f2
 * 0x9f65f8b598 0x200
 * 0x9f65f8b5a0 0x801
 * 0x9f65f8b5a8 0x1da45010150

   ... (maximum recursion depth reached.)

Let me know if further details are needed to help resolve this issue.

[cscheid]

Looks like something is causing Pandoc to crash. Could you provide us with a minimal reproducible example?