#Why does the new Typst web app cause sudden performance spikes while causing an error by an edit

14 messages · Page 1 of 1 (latest)

runic stone
#

I find that whenever I accidentally modify part of a Typst file in the editor in a way that would cause many errors to appear, the editor would spend a large amount of time processing these errors, during which no input could be inserted. If I had to guess, I would say this has to do with the longstanding desyncing issues, however frankly the current "fix", if I understand things correctly, appears to be nearly as annoying and distrupting. Would it be possible to handle input in the web app independently of the compilation system/thread?

hoary stratus
#

To be honest, this could've been phrased in friendlier way. That aside, here's the factual answer: The web app already handles input independently of compilation. There's actually even multiple compiler threads so that highlighting, compilation, and rendering aren't blocked by each other.

Does your issue only happen in larger documents? And, does it also happen if you start and then remove again a block comment instead of producing many errors? If so, I have a suspicion what may be causing the slowdown.

runic stone
# hoary stratus To be honest, this could've been phrased in friendlier way. That aside, here's t...

I'm terribly sorry. It wasn't my intention to come off in an unfriendly way. Looking back at the phrasing, yeah, I guess. I've just attempted to describe an issue which was fairly common for me, but again, I'm really sorry, and this wasn't my intention.

If I had to guess, it probably does, as it appears to only really be noticeable with large error counts. I'll check whether I can reproduce it in a small document (with a lot of errors). I've just wanted to quickly send this message, to avoid sending the wrong one.

hoary stratus
runic stone
#

Alright, consider the following document: https://typst.app/project/r4mzaoMX9-6i_t66iQSF7U

Copy it, and then remove the brace following the string "test". This is a bit more severe than the issues I have in my document, but it gets the idea across. This seems like it may be a weird edge-case, but replace all of the a's with actual words, and you'll get a "fairly normal" document.

If I had to guess, the issue is with handling the amount of errors generated in the process by the compiler. As to how to handle things, I'm probably in no position to advise, as I don't know anything really on the backend of the web app.

runic stone
#

For the record, I've been able to get on my document around 4900~ errors, while editing the top section of the main Typst file.

hoary stratus
#

@runic stone I want to apologize for my reaction to your feedback. I felt a bit offended after all my work on the web app improvements, but I do appreciate the bug report and I shouldn't have started my message this way.

runic stone
#

Absolutely no worries, I still feel like it was more a me-issue. What are your thoughts on the document I sent?

hoary stratus
runic stone
#

Alright.

runic stone
#

Any progress on understanding the root of this? Lag spikes when a large number of errors appear do still occur to me on the web app.

hoary stratus
#

I just did a test and the lag becomes a lot less bad if the 'a's aren't all in one line. I think CodeMirror (the editor we use) does a lot of work on a line-by-line basis and very long lines can then choke it. However, I assume in your real documents the lines aren't that long. So, I think main issue here is that the Typst parser generates this many errors in the first place. It should notice that something's off and not demand all those commas.

runic stone
#

Of course ideally less errors would be generated, but I think being able to handle this many errors is something the web app should fundamentally be able to do, as it is possible to have these errors to all be legitimate for large enough documents, or for these fail-safes to fail.