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.