Especially in combination with state.get(), show rules on table cells can get slow. This PR makes a series of optimizations that considerably improve run times for both the num() function and alignment of numerals in tables.
now only one state is used internally. The two additional states round-state and group-state have been incorporated into num-state.
The user can pass in a state dictionary manually to avoid state.get() being called. The default state dictionary is now exported as zero.default-state. This enables a user to redefine num via #let num = num.with(state: my-state).
In the implementation of ztable, the num-state is obtained once and passed down to all num() invocations to avoid getting the state multiple times per table.
In the implementation of num, when alignment is activated, only the existing components are now measured since the remaining ones are known to be of zero width. This is a common case since numbers in tables mostly consist of an integer and fractional part whereas the uncertainty and power components are rarely present.
Some ideas that do not (currently) lead to an improved runtime:
replacing measure(thing) with the old measure(thing, styles). This actually leads to a slightly worse performance.
going back to math.equation(..) instead of the sequence constructor for equations. It turns out that using the sequence constructor was a good idea and yields slightly better results.
Especially in combination with
state.get()
, show rules on table cells can get slow. This PR makes a series of optimizations that considerably improve run times for both thenum()
function and alignment of numerals in tables.round-state
andgroup-state
have been incorporated intonum-state
.state.get()
being called. The default state dictionary is now exported aszero.default-state
. This enables a user to redefinenum
via#let num = num.with(state: my-state)
.ztable
, thenum-state
is obtained once and passed down to allnum()
invocations to avoid getting the state multiple times per table.num
, when alignment is activated, only the existing components are now measured since the remaining ones are known to be of zero width. This is a common case since numbers in tables mostly consist of an integer and fractional part whereas the uncertainty and power components are rarely present.Some ideas that do not (currently) lead to an improved runtime:
measure(thing)
with the oldmeasure(thing, styles)
. This actually leads to a slightly worse performance.math.equation(..)
instead of the sequence constructor for equations. It turns out that using the sequence constructor was a good idea and yields slightly better results.Benchmarking results for
num
Exemplary code (for most cases)
Code for manually specifying the
state
math.eqation
while "eq seq" means using the sequence constructor for equationsBenchmarking results for
ztable
:ztable
internallyget()
s the state once and passes it on tonum()
With the new version, the runtime for
ztable
now seems to scale linearly with the number ofnum
objects inside on a large scale.