Request for Limiting Memory Use for Next Release?

Meta
1

Hi,

I wasn’t sure where to post this, but I was wondering if the Typst developers could please raise the priority of the memory consumption bugs? RAM is very expensive right now and I’ve found the out of memory issues to make Typst effectively unusable on old machines. In fact, Typst is the main reason why I’m hesitant to purchase a Macbook Neo because it only has 8 gb of RAM and on my old 16 gb of RAM machine, typst already took up all the RAM.

There are a number of Github issues since at least 2024 requesting that RAM usage be somehow limited:

  1. Limits to prevent unlimited memory consumption · Issue #3150 · typst/typst · GitHub
  2. Infinite memory consumption and overflow with specific enum show rule · Issue #6191 · typst/typst · GitHub
  3. Memory consumption and compile time - Regression from 0.14.2 to 0.15.0 · Issue #8611 · typst/typst · GitHub
  4. Out of Memory error using show rule with (par + context measure(par)) · Issue #7654 · typst/typst · GitHub
  5. Handle out-of-memory situations more gracefully · Issue #8628 · typst/typst · GitHub
3 Likes
2

The most realistic thing would be to replace all allocations by a custom allocator which is the same but counts the total currently allocated size and panics if limited reached. This would only work for typst code and not for allocating dependency crates. But you probably want to have a memory limit and still get the full pdf result, right? This would be much harder and would require heavy rewrite of the typst compiler.

3

It does seem like the RAM usage is on the Typst roadmap Roadmap - Typst Documentation

A heavy rewrite sounds like a lot of work, but I would think that the ability for Typst to be able to comfortably and reliably run on something like a Macbook Neo or even Raspberry Pi could be really important for adoption of Typst amongst new users.

Typst is already good enough for submitting the generated PDFs to journals, but the RAM usage is really limited who and how someone can actually use it. The webapp isn’t necessarily an option for everyone and even if it was, I can’t imagine that the RAM usage is a good thing for Typst’s cloud costs!

1 Like
4

The web app actually runs everything locally through wasm instead of running on a server. So even if you use the web app you have the memory issue.

4 Likes
5

I think, one problem is the “everything is immutable” design. Due to this we get 328 MB RAM usage for the following code that normally would be O(1).

#let values = (1, 7, 4, -3, 2)

#for _ in range(10000000) {
  (values.at(1), values.at(3)) = (values.at(3), values.at(1))
}


#values
1 Like
6

yeah same here. we had to fork typst and basically chunk our reports into sections and stream out the results.

7

Typsastra may be something to consider before spending time with the Typst source code. The preview functionality is already customized to use less memory, as described here:

This does not affect memory use during the actual compilation though, so if you have an automated process that you aren’t looking at previews then it will not help.

8

Arrays are not actually immutable. I didn’t check in detail, but I would suspect the RAM usage here comes from the fact that range eagerly allocates an array as Typst does not have iterators.

2 Likes
9

Yes, that makes sense. Also this simple code has the same RAM usage:

#for _ in range(10000000) {

}

I see, the docs even say that range creates an array. This is then different to Python. Though, you could check at VM level if it is used as an iterator and then rewrite it as a while loop.

10

Yeah that’s possible and will probably happen at some point.

2 Likes