followingup-performance.tex /size: 5643 b    last modification: 2021-10-28 13:50
1% language=us runpath=texruns:manuals/followingup
2
3\startcomponent followingup-performance
4
5\environment followingup-style
6
7\startchapter[title={Performance}]
8
9\startsection[title={Introduction}]
10
11Those who've read the other documents describing the development of \LUATEX, know
12that performance is always on my radar. A decent performance is a must for a
13useable workflow, especially because typesetting is a multi|-|pass process.
14\footnote {I'm often baffled by reports of (non|-|\CONTEXT) \LUATEX\ users about
15the performance of \LUATEX. It seems easier to blame an engine than ones own
16macros or setup and most of those tests make no sense anyway. Believe it or not,
17but if performance of \CONTEXT\ \MKIV\ was much worse than \MKII\ (using \PDFTEX\
18or \XETEX) it would have backfired and the project would never have taken of.
19Just think of this: would Hans really use \LUATEX\ and continue with development
20if it were that slow?} One page reference changing from two digits to three
21digits can influence whatever follows and we're not only talking of a different
22page break, even a change in line breaks can have consequences. The core engine
23cannot be made much faster. When the (single core) run has the whole cpu
24available not much can be gained. But multiple processes are run at the same
25time, the cache has to be shared and misses can become an issue. So, efficiency
26of code is still important. Occasionally a (tiny) improvement can be made, but
27only the accumulation of such improvements can make a dent. The feeling is that
28over time \LUATEX\ has not become slower but we keep an eye on possible other
29improvements. The memory footprint is also something to keep an eye on. \footnote
30{Of course this is all becoming less relevant now that having e.g. a browser open
31in the background will set you back with a constant 5\endash10\% cpu load and
32slowly accumulating gigabyte memory usage. That actually was something I had to
33keep in mind when running \LUAMETATEX\ benchmarks.}
34
35The more we delegate to \LUA, the less we can benefit from for instance \CPU\
36improvements: in that case the \LUA\ virtual machine is the bottleneck. And there
37is not much we can do about that. This also means that when we delegate more to
38\LUA\ we sacrifice performance. Sometimes things can be done more efficient in
39\LUA, but those are often tasks that are not performed frequently. That said, I'm
40convinced most of the \CONTEXT\ code is quite efficient and not much can be
41gained.
42
43The biggest change in \LUAMETATEX\ is the backend. We gain some efficiency in
44terms of speed, performance and output in some cases, while in other cases we
45loose a bit. On the average the small performance hit is bearable. Because
46\CONTEXT\ users don't complain about performance I think that I have some slack
47here.
48
49\stopsection
50
51\startsection[title={An example}]
52
53There are a few places where \LUATEX\ looks ahead to check something and goes back
54when the condition is not met. Take these:
55
56\starttyping
57\hbox   {...}
58\hbox   to 10cm {...}
59\hrule  width 10cm height 10cm \relax
60\dimen0 =10cm
61\dimen0 10cm
62\mydimen 10cm
63\toks0  {...}
64\toks0  \toks2
65\stoptyping
66
67Spaces and sometimes \type {\relax} after the trigger (\type {\hbox}, \type
68{\dimen}, etc.) are skipped and in some case there can be an optional \type {=}
69sign. So, there are quite some cases where there is first a check for an optional
70equal which itself can be preceded by optional spaces. When there is no equal
71sign the last seen token is pushed back into the scanned which effectively means
72that a temporary token is allocated, and a one token list is pushed on the input
73stack. Then scanning goes on. The same can happen with the open brace in case of
74a token list assignment: it gets pushed back and the content scanned checks it
75again. In the case of keywords something similar takes place, because here
76\LUATEX\ checks explicitly for e.g.\ type {width}, and when it is not found again
77it pushes back consumed tokens and checks for the \type {width}. In the case of
78the specifiers of the box we don't need to check at all when we have an opening
79brace. In the follow up, when the \type {orientation} keyword was added, and the
80\type {dir} and \type {bdir} were replaced by \type {direction} a little bit more
81was optimized.
82
83In \LUATEX\ this code comes from \PDFTEX\ which takes if from \TEX, but in both
84cases some code side effects occur from the transition from \PASCAL\ to \CCODE.
85But, in \LUATEX\ we stick to the \CCODE, so we can try to get rid of these
86artifacts. During the last years, especially when additional keywords were
87introduces (for instance for attributes) already some optimization took place. In
88the follow up again some optimizations were applied, for instance quite often we
89can combine the check for an equal sign with skipping the spaces.
90
91The gain is not spectacular but as all small bits add up eventually it is
92measurable in a complex run. What definitely is true, is that we avoid some
93memory access which in turn might pay back when multiple runs happen in parallel.
94
95Of course one can argue that such optimizations are to be avoided but as long as
96they don't obscure the code, it's okay. After all, just as one optimizes for
97instance a compression algorithm or search routine, there is no reason not to
98mildly optimize some of the critical code in \LUATEX. And in \CONTEXT\ we have
99plenty of opportunities to check if that works out well. At some point some might
100be retrofit into \LUATEX\ 1.2 (or later). \footnote {But it makes less sense now
101that there are variants popping up that might depend on the stable base.}
102
103\stopsection
104
105\stopchapter
106
107\stopcomponent
108