polylux icon indicating copy to clipboard operation
polylux copied to clipboard

Performance

Open Mc-Zen opened this issue 1 year ago • 9 comments

Hi,

I've noticed that the performance suffered significantly from the last update (going from 0.2.0 to 0.3.1). I've made some experiments and found that this is greatly due to the new implementation of pausing. As I understand, all possible elements are set to be hidden and unveiled via a dynamic show rule that makes a check for the current location. However, this results in a huge number of locate() calls which are known to be slow (see tablex). In combination with more complex content (such as diagrams or tablex tables) that consists of many lines for example, this slows down the compilation very much (actually my slides are now - after the update - by far slower than the Latex version from which I converted them and these were already slow!). Unfortunately, incremental compilation also seems somewhat broken with the slides and so compiling now takes several minutes for each edit.

The new implementation of pause is really neat in usage but the disadvantages might outweigh this ...

I experimented with implementing a very basic slide framework recently and I think that it would generally be possible to overcome the performance issues. The main issue seems to be the pause and maybe it could be replaced with some automatic uncover function (this name is of course already used, so maybe something else) that works somewhat like this

#slide[
  #uncover[I want to say something]

  #uncover[This is it!]
]

Equivalent to (and not much longer or more verbose):

#slide[
  #pause
  I want to say something

  #pause 
  This is it!
]

The feature uncover would keep track and update a pause-counter internally and show or hide its content depending on the relation of the pause-counter and the subslide-counter. This is pretty simple in implementatiaon and provides fast compile times. Also nested uncovers seem to work at first sight :)

That being said, I still love polylux of course! It would just be great to work on the limitations for longer or more complex presentations because I think polylux might stay around for a long time and also it already has a wonderful feature support.

Mc-Zen avatar Nov 23 '23 14:11 Mc-Zen

PS: I could potentially make a pull request if you're short on time currently and if there is something agreed upon

Mc-Zen avatar Nov 23 '23 15:11 Mc-Zen

Hey, can you time the compilation again with Typst 0.10.0? Several minutes sounds awful...

andreasKroepelin avatar Dec 06 '23 08:12 andreasKroepelin

Hi, yes with Typst 0.10 it is 4:45min. For comparison: with polylux:0.2.0 the same project takes 15 seconds.

Mc-Zen avatar Dec 06 '23 09:12 Mc-Zen

It also is not a scalable approach for when typst allows users to create their own types (https://discord.com/channels/1054443721975922748/1175895383600275516)

ntjess avatar Dec 14 '23 08:12 ntjess

It also is not a scalable approach for when typst allows users to create their own types (https://discord.com/channels/1054443721975922748/1175895383600275516)

That's true, unfortunately.

andreasKroepelin avatar Dec 14 '23 10:12 andreasKroepelin

Another update: If I understand correctly, with revoke rules (https://github.com/typst/typst/issues/420#issuecomment-1893427824), revoking almost anything will break the pause logic since rules are reset to their base behavior

ntjess avatar Feb 24 '24 06:02 ntjess

Good point... yeah the current pause mechanism is just not as good of an idea as I thought at the time. I really want something like this in Polylux but it's just very tricky to implement.

andreasKroepelin avatar Feb 24 '24 09:02 andreasKroepelin

I'm rewriting my slides in polylux and while I really like the experience, thanks for a great tool! However, I have stumbled on the performance issues. I typically have ~50 slides with few images and a lot of code snippets. I haven't used pause/one-by-one or any "dynamic" features but the compilation times are growing with the number of slides. I have compared 0.3.1 and 0.2.0 and there's a big performance difference, compiling from scratch gets roughly 11s and 3s respectively, while incremental compilation yields consistently ~4-5s vs ~60-600ms. I don't mind waiting even several minutes to compile final version but several seconds of incremental compilation just to add few lines of text gets annoying. Currently when working on the slides I use 0.2.0 and then switch to 0.3.1 to get pdfpc notes, but maybe providing a switch which basically turns off locate/context features in "dev" and turns them on in "release" mode is one way to mitigate the issue?

fuine avatar Mar 08 '24 12:03 fuine

Thanks for your perspective. Several seconds for incremental compilation is indeed too long.

andreasKroepelin avatar Mar 08 '24 14:03 andreasKroepelin