#Bad compile time

1 messages · Page 1 of 1 (latest)

gilded anvil
#

I get bad incremental compile time (up to 7 seconds) in a document with a lot of Cetz pictures imported like this:

#figure()[#include "pictures\sis_transitorio_rc_graph_v.typ"]

and the file imported is like this:

#import "@preview/cetz:0.1.1": canvas, plot, draw #set text(size: 20pt) #canvas(length: 1cm, { draw.scale(2) draw.set-style(mark: (fill: black)) plot.plot(size: (10, 4.5), axis-style: "school-book", y-tick-step: none, x-tick-step: none, x-ticks: (0, (5, $tau$), (25, [$5 tau$]),), y-ticks: ((0.632, $0.632 dot V_C^f$), (1, $V_C^f$),), x-label: $t$, y-label: $v_C$, y-max: 1.1, { plot.add(style: (stroke: (paint: red, thickness: 2pt)), domain: (0, 30), x => 1 - calc.pow(calc.e, -x/5)) plot.add(style: (stroke: (paint: red, thickness: 2pt)), domain: (-5, 0), x => 0) plot.add(style: (stroke: (dash: "dashed")), domain: (0, 30), x => 1) plot.add(style: (stroke: (dash: "dashed")), domain: (0, 5), x => 0.632) plot.add(style: (stroke: (dash: "dashed")), domain: (0, 30), ((25,0), (25,1))) plot.add(style: (stroke: (dash: "dashed")), domain: (0, 30), ((5,0), (5,0.632))) }) })

Replacing the

#figure()[#include "pictures\sis_transitorio_rc_graph_v.typ"]

with box() get again 500ms of compile time. I thought that the included files where cached, but this is not the case. Any advice? Thanks a lot!!

ancient temple
#

I have trouble reproducing this. Is it possible for you to share your document or create a simplified version of this?

gilded anvil
ancient temple
gilded anvil
ancient temple
#

Thanks!

dapper turret
#

For me it only takes around 4 seconds (which I guess is still quite a bit, especially for a document of this size)

#

I guess it also depends on your hardware?

ancient temple
#

4s is quite slow because without the figures it takes 200ms

#

And the figures should be trivial to memoize

#

I'm currently trying to find out why it can't cache them

ancient temple
#

@dapper turret I believe this is the nested show rule issue again

#

I have now finally understood why it is a problem

#

The context (the StyleChain) is generally hashed for memoization purposes. When you have a template-like show rule, that gets the body of the whole document, and within it you have show rules with closures, then perhaps these closures capture the body, which becomes part of their hash. These closures then become part of the local style chains and as such they are never memoized. I think that could be it at least.

#

The closures shouldn't capture unused variables though, so either the capturing is not working correctly or this isn't the whole story.

dapper turret
#

Hm I see

#

Well I have to admit I’m not very familiar with that part of the code base so I won’t be able to debug it :(

#

But hopefully it’s an easy fix

ancient temple
#

I can definitely confirm the issue. The style hash changes from every modification to the document in the nested show rule issue.

ancient temple
#

I'm a bit excited now. Maybe this will fix tablex memoization, too!

#

Ok, so it's kind of what I expected

#

Because it and body are used so often in Typst documents, the closures sometimes capture things unnecessarily that would be shadowed

#

But that shouldn't be too hard to fix!

dapper turret
#

If you do manage to fix it maybe this would even warrant a hot fix for the web app (like a minor release of the compiler) since this would improve the whole experience by a lot

ancient temple
#

(The web app is actually still up to date with Typst main since there were only bug fixes since the release.)

#

Perhaps this would even warrant 0.8.1

pastel anvil
ancient temple
#

And I have a fix!

#

Fix is pushed.

dapper turret
#

Nice! So fix to web app is coming as well? 😄

ancient temple
#

Yeah, will take maybe 15 mins

dapper turret
#

Maybe this will also fix it for the person who added many svgs!

ancient temple
#

That would be great, but I'm not so optimistic. I don't see how it would help.

#

SVG decoding and SVG embedding shouldn't depend on the style chain hash.

#

But here's to hoping it helps anyway!

#

@gilded anvil The bug is fixed and the fix also already in the web app. The preview is now instant again for your presentation on my machine. :)

autumn parrot
#

I am the guy adding many svgs and I am very excited by this fix 😀! Can we update Typst CLI using typst update ?

pastel anvil
#

Not yet, only when (and if) there will be 0.8.1 release version. It may appear soon, but not immediately. The only way for now is compiling from source (or asking someone else to do it).

dapper turret
autumn parrot
#

Perhaps, but it probably will improve the compilation time, since I have nested show rules in my template

dapper turret
#

If you use the web app it should already be there, if not you will have to compile from source I think, not sure if Laurenz plans to make a minor release

ancient temple
#

I'll probably make a minor release next week, perhaps fix one or two more bugs before that.

glossy hemlock
#

@ancient temple @dapper turret Zooming the document with svg and png images was causing recompilation in the web. After release 0.8.0 that time shortened. Should I see the difference now? It seems the same for me now, fairly quick (1-2 secs), but not instant.

ancient temple
#

You mean zooming in the preview without any typing?

glossy hemlock
#

yep

ancient temple
#

That shouldn't be affected by this fix

#

If zooming is slow, then the renderer is slow as no new compilation will happen.

#

The renderer is unfortunately just not that fast. It doesn't run on the GPU. But if it's 1-2s slow (i.e. real slow), maybe there's still something we can improve.

glossy hemlock
#

Frankly, 1-2 secs is something I can leave with. After LaTeX everything looks instant...

ancient temple
#

Is the typing without zooming fast at least?

#

That's the typical situation after all.

gilded anvil
#

Thanks very much!!! I'm looking forward version 0.8.1 😍

glossy hemlock
gilded anvil
#

Compiled the last version and works perfectly also from command line!

gilded anvil
ancient temple
#

Strange

gilded anvil
#

it randomly happen if I change context. For example, i edit text, then i edit math blocks, and it happens

#

Also in the web app. I've tried

#

But is not a big problem. It's 100 times better than before!

gilded anvil
# ancient temple Strange

Hi, I was working on the presentation, and sadly the compile time is still a problem. I get very often 4-6 seconds of compile time while editing equations or columns. I think there is still some problem with the cache and i see it beacuse my document has a very long "first compile time" and so I can feel when the cache is invalidated. I was think about to open another issue on Github

ancient temple
#

with the math blocks or something else?

gilded anvil
#

I think that the fix that you have done is somehow get ignored when switching from text to math. Because if I make 10 edits on the text, I get always good compile time. If I edit equations, I get very often bad compile time.

ancient temple
#

I will look into it.

#

@gilded anvil are you experiencing this locally or in the web app?

gilded anvil
#

I'm currently working locally with the last main branch compiled, but I've experienced also in the web app.

ancient temple
#

Locally, I can reproduce it. In the web app not.

#

The difference being that the web app performs incremental parsing, which has effects way beyond the parsing time because certain information about the source file remains stable

#

There is an improvement which would fix this locally, but it's not yet implemented

gilded anvil
#

Ok, I've understood. I think that the most smart way is comment out all the text while working on new feature and decomment in the end before compiling....

ancient temple
#

do you mean with "feature", when you're working on something in the template?

gilded anvil
#

No, I mean when I add pages to an already big file

#

Or if I edit the template, of course

ancient temple
#

If you edit the template, it's difficult to provide real-time preview as it affects a lot of stuff

#

But when adding pages to a big file, it's of course not what we're striving for with Typst that you have to comment stuff out

#

The problem with the local compiler vs. web app can be resolved without too much work

#

However, I still am not sure what the problem is in the web app. It could be related because incremental parsing also doesn't always work that great. But I wonder whether it's this or something else.

gilded anvil
#

I could try using more the web app and see how often I have problems...beacuse at them moment I've worked 100% of the time offline

ancient temple
#

However you like

#

I will try to implement the improvement sometime soon

gilded anvil
#

Thanks a lot!

teal sand
ancient temple
teal sand
#

👀 I use Source::edit, isn't it making spans stable?

ancient temple
# teal sand 👀 I use `Source::edit`, isn't it making spans stable?

It does make them stable, it's fine. I just wasn't sure whether computing a full diff like you do is really worth it (if it dispatches multiple edits for multiple ranges that might be slower than parsing from scratch). Because the tree-based renumbering approach was a bit trickier than antipicated, in the end I opted for a naive diff (suffix+prefix) + edit: https://github.com/typst/typst/commit/5ef2842c3687469f3902a869a610cfdfda595bae

#

I also implemented an optimization with the file timestamp like you did.

teal sand
ancient temple
#

in the end, it probably doesn't make much of a difference. but it's nice to skip the dependency on dissimilar.

teal sand
ancient temple
#

It's not smarter. It just uses a more naive diffing approach, which makes no real difference in practice probably.

teal sand
#

@ancient temple back to bad compile time, does reparsing solve the problem?

ancient temple
#

I believe so. Previously all spans in the file would change on pretty much any edit. If you had a single recursive show rule in such a file, it would wreck incremental compilation because the show rule's hash changes.

#

@gilded anvil The latest changes on main should improve incremental compilation locally.

teal sand
ancient temple
teal sand
#

I mean the Source::replace will have same performance as computing a full diff and editing them one by one when the edition typically happens in a single place. And it really skips the dependency on dissimilar.

gilded anvil
ancient temple
gilded anvil