I take notes at GitHub - saffronner/15351-notes with tinymist and VSCode. But it seems to be chugging RAM while running the tinymist preview—in particular, the preview isn’t quite instant anymore (stutters), and RAM attributed to the tinymist process rises as much tens or hundreds of megabytes every few words.
In particular,
changes appended to end of file
ram usage after change
<initial reading>
685.01MB
test test yippee!\n
741.70MB
\ndoing this again.\n
874.64MB
#pagebreak()\n
1.20GB
#pagebreak()\n
1.44GB
RAM usage is not so crazy when I remove all fletcher diagrams, and the preview likewise becomes instant again.
I guess my specific questions are:
does this happen to just me?
why does this happen? are there typst or fletcher optimization footguns I should know about?
You can always use swap files. I got recommended GitHub - Tookmund/Swapspace: A fork of Jeroen T. Vermeulen's excellent dynamic swap space manager and it’s a good compromise. No more swap partitions or big manual swap files. With some GNOME extensions (I don’t know why GNOME is always so broken) on my machine, a lot of RAM gets leaked, and without swap my machine literally dies unless OOM killer saves it in time. Now I just don’t think about this anymore. Both, because I still didn’t re-enable those extensions and now I kind of have to reboot my machine pretty regularly.
What I found with big projects with many different figures, is that typst watch will always recompile from scratch after like 10 superfast incremental compilations. This is quite annoying. I sometimes need to tweak something small and preview it, but suddenly it freezes, and it’s actually just re-compiling the whole thing and I have to wait for at least 7 seconds or so. I never heard anyone having such an issue, but it’s unrelated to Tinymist. Though they still share a lot of common code, and I can’t see when Tinymist starts and finishes it’s re-compilation.
Compile from scratch also sounds like a good thing in the context of this question. Then it can drop the incremental cache, reclaim memory and make sure memory use does not increase without bound.
I’m pretty sure the memory usage only increases with time, I don’t think I’ve ever seen it dropped, though I don’t regularly watch the RAM consumption when I’m using Typst. And it’s more annoying for it to do this so frequently rather than doing it like once in 50 or 100, if it is necessary at all.
In my informal experiments on my file above, I’ve seen it decrease by a few megabytes or whatever every once in a while (while I increase file length by typing out plaintext), even while most bytes added to the file correspond to massive increases.
This seems like an issue with memorization and incremental compilation. I’ve seen things like this on early Typst versions, but they all should have got fixed.
If you could provide some reproducible example and confirm that this behaviour applies not only to Tinymist, but also to webapp or cli, it would be good to make an issue on Github.
Hm, interesting! I’ll keep that in mind, but I don’t have the bandwith right now to properly isolate and such. Maybe some other day, or week, or some other party happens along and finds this interesting.
Marking this as the answer to my explicit questions, even though the issue isn’t really resolved (as a workaround I’ve gone back to the “latex-style” workflow for this document, where I manually trigger document compilation and view the pdf, instead of letting tinymist preview on edit).
This is because every point/vector/tensor operation in fletcher and cetz is cached. in multi-thread env (tinymist), this is worse because cache checks happen in different threads for a same tensor operation call. I think you could recheck it in typst v0.14, because some related optimizations will be launched. Altho, typst should still identify and optimize cache efficiency for these small function calls. I mean typst v0.14 still caches all user function calls.
A better workaround would be splitting the document into several parts that can be compiled separately, like chapters, if possible. There are also some workarounds (quite obvious show-rules) to avoid references panicking if referencing something from other chapters.
Maybe even better solution would be making fletcher diagrams separate documents that compile into SVG that could be inserted in the document without big memory requirements. It’s a bit tedious and is basically impossible to do on webapp, but instant preview is worth it. You can make it toggable to make final compiles from source, not from images, though there could be not much reason to do so.