#The compiler ran out of memory
42 messages · Page 1 of 1 (latest)
would seem weird that the compiler runs out of memory after just a few pages, any way you can share the document (only if not private ofc) or a similar small example?
other than that, if you have any show rules or so, try temporarily removing them and see if that resolves the problem, if so perhaps you have some kind of recursive show rule
IIUC the document is large and it does compile ("Some pages compile") successfully but then runs out of memory after rendering a few pages.
Here is a link to a copy of the project (sorry, it's in Spanish, but I don't think it's relevant).
It's more than 100 slides using Polylux, maybe too many images, any way to optimize it?
(link deleted) (please, ask if you need it)
okay so the preview works, but PDF export fails
but once you try to export it, the preview then doesn't work anymore either
somehow my polylux projects always end up being way more expensive than "articles"
yeah it's possible the way polylux works is not great for memory 😄 but I'm not sure
I'm not sure whether it's polylux itself or a disproportionate usage of cetz/fletcher on slides
I've tried commenting slides until it stops crashing (about halfway through the document).
So it seems. I'll have to compile it locally for now.
Yeah, compiling local is the easiest fix for now
(btw tho I think you with the link you shared others have write permissions. maybe you should delete the link and only share it with read, since this is a public server)
We really need to optimize memory usage soon-ish, it hasn't been a focus area so far.
No problem, that's a copy of the original project.
I'll change it anyways
I don't think cetz/fletcher is actually used
ah yes
No, it's not
is it possible that it somehow memoizes more stuff on the web version? @fresh sonnet
I saw your contact form submission. Since we're discussing it here now, I won't answer there anymore, just so you know.
Fine, no problem 👍
why?
or is it just that the wasm memory limit is lower?
just wondering because I dont seem to have problems compiling it locally at all
yes, WASM is always limited to 4GB
it's 32 bit
that's why we can all perfectly reproduce it
4GB should be plenty if we wouldn't memoize everything left and right
yep, local compiling works fine for me. Seems like a web app limitation ?
okay yeah so this is what I get if I run watch locally
but good that the document can be compiled at least 😄 haha
yeah, the web app uses some extra memory for rendering etc. so it is just enough for compile, but then it goes OOM.
Does comemo use compression at all? I assume a lot of what's being stored has massive overlaps.
Even when memoizing everything it seems like you could claw back some memory that way
It stores in-memory data structures, not serialized data, so it cannot transparently compress anything. There is probably quite a bit of duplication, but many things are also shared through reference-counted pointers.
I wonder if memory bandwidth is a bottleneck at all
https://crates.io/crates/sucds https://crates.io/crates/sux these seem interesting, but presumably not useful for typst
Unfortunately if it stores hashes, hash of arc of T is equal to hash of T
Doesn't it store hash to compare equality?
I'm not sure I understand what you mean. Why is it unfortunate?
Because it's storing the same hash again and again when I'd hope for compression?