2023-01-15 13:55:00

4 files changed, 715 insertions, 8 deletions

diff --git a/doc/context/sources/general/manuals/lowlevel/lowlevel-boxes.tex b/doc/context/sources/general/manuals/lowlevel/lowlevel-boxes.tex
index 550e06819..e2e34bd20 100644
--- a/doc/context/sources/general/manuals/lowlevel/lowlevel-boxes.tex
+++ b/doc/context/sources/general/manuals/lowlevel/lowlevel-boxes.tex
@@ -897,3 +897,15 @@ that users will find reasons to abuse this effect.
 %
 % test \par \box0 \par \box2 \par test
 
+
+\setbox0\vbox
+{
+    \setbox    \scratchbox      \hbox{XXX}
+    \boxvadjust\scratchbox pre       {BBB}
+    \boxvadjust\scratchbox post      {AAA}
+%     \dontleavehmode % needed
+    \box\scratchbox
+%     \unhbox\scratchbox
+}
+
+111111\par \box0 \par 222222\par
diff --git a/doc/context/sources/general/manuals/math/math-notdone.tex b/doc/context/sources/general/manuals/math/math-notdone.tex
index 757cebbe2..9cb5c8027 100644
--- a/doc/context/sources/general/manuals/math/math-notdone.tex
+++ b/doc/context/sources/general/manuals/math/math-notdone.tex
@@ -9,7 +9,7 @@
 \startchapter[title=Why we don't do this]
 
 The \TEX\ engine has two math modes: inline and display. What exactly happens
-before we do that depends on what mode we are in.
+before we enter math depends on what mode we are in.
 
 \startitemize
     \startitem
@@ -25,7 +25,7 @@ before we do that depends on what mode we are in.
         indentation and everything that \type {\everypar} likes to inject. Inline
         math then stays inline but display math starts out with flushing the
         current paragraph and that happens to be the state, indentation and
-        everything else injected at the beginning. Often nothing is sees, just
+        everything else injected at the beginning. Often nothing is seen, just
         an empty line sits there.
     \stopitem
     \startitem
@@ -35,7 +35,7 @@ before we do that depends on what mode we are in.
 \stopitemize
 
 Especially the second case is tricky. The \quote {empty} line is placed with
-proper \type {\parskip}, \type {\parindent} and whatever. That can end up with a
+proper \typ {\parskip}, \typ {\parindent} and whatever. That can end up with a
 lot of supposedly whitespace of which is not really clear (for the user) what
 comes from where: interline space, whitespace, line height, display spacing, etc.
 To that you can add that empty lines are special themselves: in \MKII\ we relax
@@ -43,8 +43,8 @@ To that you can add that empty lines are special themselves: in \MKII\ we relax
 \LUAMETATEX\ has no checks at all. \footnote {The same can be told about \type
 {\outer}.}
 
-Before We show some examples of this we have to make clear that \CONTEXT\ users
-don't do this have to worry about all this. We don't follow the (Plain and
+Before we show some examples of this we have to make clear that \CONTEXT\ users
+don't have to worry about all this. We don't follow the (Plain and
 \LATEX) \AMS\ policy of \quotation {no empty lines before display math} and
 \quotation {no empty lines in display math}. We don't even use the display skip
 parameters and we do compensate for these empty line issues. The basics haven't
@@ -112,9 +112,9 @@ make sure that we operate in regular \TEX\ mode, the way other macro packages do
 
 First we show what we get with \typ {\mathdisplayskipmode 1}. This makes the
 engine behave like other engines. We don't show what we get with \typ
-{\mathdisplayskipmode 2} where zero skips are ignored but we don't have these
-here. Last we show what we get with \typ {\mathdisplayskipmode 3}. In this
-example the math specific skips are completely ignored.
+{\mathdisplayskipmode 2} where zero skips are ignored but we don't have these.
+Last we show what we get with \typ {\mathdisplayskipmode 3}. Here the math
+specific skips are completely ignored.
 
 In both shown cases you will notice that the \type {\parskip} and \type
 {\baselineskip} interfere which in turn demonstrates why in \CONTEXT\ we always
@@ -134,6 +134,13 @@ macro packages will use it no time will be wasted on this.
 {\mathdisplayskipmode 1 \getbuffer}
 {\mathdisplayskipmode 3 \getbuffer}
 
+
+% \mathdisplaymode 0
+% before \par $$             \vadjust {\bf post 1} \vadjust {\bf post 2} x_2 \vadjust pre {\bf pre} $$ \par after \blank[3*line]
+% before \par $$             \vadjust {\bf post 1} \vadjust {\bf post 2} x_2 \vadjust pre {\bf pre} $$ \par after \blank[3*line]
+% before \par $              \vadjust {\bf post 1} \vadjust {\bf post 2} x_3 \vadjust pre {\bf pre} $  \par after \blank[3*line]
+% before \par $\displaystyle \vadjust {\bf post 1} \vadjust {\bf post 2} x_3 \vadjust pre {\bf pre} $  \par after \blank[3*line]
+
 \stopchapter
 
 \stopcomponent
diff --git a/doc/context/sources/general/manuals/musings/musings-speed.tex b/doc/context/sources/general/manuals/musings/musings-speed.tex
new file mode 100644
index 000000000..ecf6d220b
--- /dev/null
+++ b/doc/context/sources/general/manuals/musings/musings-speed.tex
@@ -0,0 +1,687 @@
+% language=us runpath=texruns:manuals/musings
+
+% musical timestamp: listening to FLUX (jazz trio) in Januari 2023
+
+\startcomponent musings-speed
+
+\environment musings-style
+
+\startchapter[title={Speeding up \TEX}]
+
+\startsection[title={Introduction}]
+
+Recently a couple of cordless phones that I use gave up as soon as I used them
+for a minute or so. The first time that happened I figured that after all these
+years the batteries had gone bad and after some testing I decided to replace
+them. I got some of these high end batteries that discharge slowly and store a
+lot of power. Within a year they were dead too. Then I went for the more regular
+and cheaper ones, again with a lot of capacity. And yes, these also gave up, that
+is: only in the phones that were hardly used. The batteries lasted longer in
+phones that were discharged by usage daily.
+
+When I went out for new batteries I was asked if I needed them for cordless
+phones and, surprise, was given special ones that actually stored less but were
+guaranteed to work for at least 6 years. The package explicitly mentioned use in
+cordless phones. So here performance doesn't come with the most high end ones,
+based on specifications that impress.
+
+This is also true for computers that are used to process \TEX\ documents. More
+cores amount to much accumulated processing power but for a single core \TEX\
+process, a few fast cores are more relevant than plenty slower ones that run in
+parallel. More memory helps but compared to other processes \TEX\ actually
+doesn't use that much memory. And disk speed matters but less so when the
+operating system caches files. What does play a role are cpu caches because \TEX\
+is very memory intense and processing is not concentrated in a few functions. But
+a large cache shared among many (busy) cores makes for a less impressive
+performance.
+
+So what matters really? In the next sections we will explore a few points of
+view. It's not some advertisement for a specific engine, but much more about
+putting it into perspective (as one can run into ridiculous arguments on the
+web). It is not only the hardware and software that matters but also how one uses
+it.
+
+\stopsection
+
+\startsection[title=The engine]
+
+There are various ways to compare engines and each has its own characteristics.
+The \PDFTEX\ engine is closest to the original. It directly produces the output
+which can give it an edge. It is eight bit and therefore uses small fonts and
+internally all that is related to fonts and characters is also small. This means
+that there is little overhead in typesetting a paragraph: hyphenation, ligature
+building and kerning are interwoven and perform well.
+
+The \XETEX\ engine supports wide fonts and \UNICODE\ and therefore can be seen as
+32 bit. I never looked into the code so I can't tell how far that goes but
+performance is definitely less than \PDFTEX. The rendering of text is delegated
+to a library (there were some changes in that along its development) which is
+less efficient than the built in \PDFTEX\ route. But it is also more powerful.
+
+The \LUATEX\ engine is mostly 32 bit and delegates non standard font handling to
+\LUA\ which comes with a performance penalty but also adds a lot of flexibility.
+Also, the fact that one can call out to \LUA\ in many places makes that one can
+not really blame the engine for performance hits. The fact that hyphenation,
+ligature building and kerning is split comes at a small price too. We have larger
+nodes so compared to \PDFTEX\ more memory is used and accessed. Some mechanisms
+are actually more efficient, like font expansion and protrusion.
+
+The \LUAMETATEX\ engine lacks a font loader (but it does have the traditional
+renderer on board) and it has no backend. So even more is delegated to \LUA,
+which in turn makes this the slowest of the lot. And, again more data travels
+with nodes. In some modes of operation much more calculations take place.
+However, because it has an enriched macro processor, additional primitives, and
+plenty deep down \quote {improvements} it can perform better than \LUATEX\ (and
+even \LUAJITTEX, the \LUATEX\ version with a faster but limited \LUA\ virtual
+machine). And as with \LUATEX, there are usage patterns that make it faster than
+\PDFTEX.
+
+So, in general the order of performance is \PDFTEX, \XETEX, \LUAJITTEX\ (kind of
+obsolete), \LUATEX, \LUAMETATEX. But then, how come that \CONTEXT\ users never
+complain about performance? The reasons is simple: performance is quite okay and
+as it is relative to what one does, a user will accept a drop in performance when
+more has to be done. When we moved on from \LUATEX\ to \LUAMETATEX\ there
+definitely was a drop in performance, simply because of the \LUA\ backend.
+Because upgrading happened in small (but continuous) steps, right from the start
+the new engine was good enough to be used in production which is why most users
+switched to \LMTX\ as soon as became clear that this is where the progress is
+made.
+
+There were no real complaints about the upto 15\percent\ initial performance drop
+which indicates that for most users it doesn't matter that much. As the engine
+evolved we could gain some back and now \LUAMETATEX\ ends up between \PDFTEX\ and
+\LUATEX\ and in many modern scenarios even comes out first. The fact that in the
+meantime we can be much faster than \LUATEX\ did get noticed (when asked).
+However, as development takes years updating a machine in the meantime puts
+discussions about performance in a different (causality) perspective anyway.
+
+\stopsection
+
+\startsection[title=The coding]
+
+Performance can increase when native engine features are used instead of complex
+macros that have to work around limitations. It can also decrease when new
+features are used that add complex functionality. And when an engine extends
+existing functionality that is likely to come at a price. So where \LUAMETATEX\
+provides a more rich programming environment, it also had a more complex par
+builder, page builder, insert, mark and adjust handling, plenty of extra
+character, rule and box features and all of that definitely adds some overhead.
+Quite often a gain in simplicity (nicer and more efficient macros) compensate the
+more complex features. That is because on the average the engine doesn't do that
+much (tens of thousands of the same) complex macro expansion and also doesn't
+demand that much complex low level typesetting. A gain here is often compensated
+by a loss there. This is one reason why during the years \LUAMETATEX\ could
+sustain a decent performance. Personally I don't accept a drop in performance
+easily which is why in practice most mechanism, even when extended, probably
+perform better but I'm not going to prove that observation.
+
+One important reason why \CONTEXT\ \LMTX\ with \LUAMETATEX\ is faster than its
+ancestors is that we got rid of some intermediate programming layers. Most users
+have never seen the auxiliary macros or implementation details but plenty were
+used in \MKII\ and \MKIV. Of course we kept them because often they are nicer
+than many lines of primitive code, but only a few (and less in the future) are
+used in the core. Examples are multi step macros (that pick up arguments) that
+became single step and complex if tests that became inline native tests. Because
+\CONTEXT\ always had a high level of abstraction consistency of the interface
+also makes that we don't need many helpers. When some features (like for instance
+box manipulation) got extended one could expect a performance hit due to more
+extensive optional keyword scanning in the engine but that was compensated by
+improved scanners. The same is true for scanning numbers and dimensions. So, more
+functionality doesn't always come at a price.
+
+To summarize this: although the engine went a bit more \quote {cisc} than \type
+{risc} the macro package went more \quote {risc}. It reminds me a bit of the end
+of the previous century when there was much talk of fourth generation languages,
+something on top of the normal languages. In the end it were scripting languages
+that became the fashion while traditional languages like \CCODE\ remained
+relatively stable and unchanged for implementing them (and more). A similar
+observation can be made for \CONTEXT\ itself. Whenever some new feature gets
+added to an existing mechanism I try to not cripple performance and thanks to the
+way \CONTEXT\ is set up it works out okay.
+
+Let's look at an example. In \MKII\ we can compare two \quote {strings} with the
+macro \type {doifelse}. Its definition is as follows:
+
+\starttyping
+\long\def\doifelse#1#2%
+  {\let\donottest\dontprocesstest
+   \edef\!!stringa{#1}%
+   \edef\!!stringb{#2}%
+   \let\donottest\doprocesstest
+   \ifx\!!stringa\!!stringb
+     \expandafter\firstoftwoarguments
+   \else
+     \expandafter\secondoftwoarguments
+   \fi}
+\stoptyping
+
+This macro takes two arguments that gets expanded inside two helpers that we
+then compare with a primitive \type {\ifx}. Depending on the outcome we
+expand one of the two following arguments but first we get rid of the interfering
+\type {\else} and \type {\fi}. The pushing and popping of \type {\donottest} takes
+care of protection of unwanted expansion in an \type {\edef}. Many functional macros
+are what we call protected: then expand in two steps depending on the embedded
+\type {\donottest} macro. Think of (simplified):
+
+\starttyping
+\def\realfoo{something is done here}
+\def\usedfoo{\donottest\realfoo}
+\stoptyping
+
+Normally \type {\donottest} is doing nothing so \type {\realfoo} gets expanded
+but there are cases where we (for instance) \type {\let} it be \type {\string}
+which then serializes the macro. This is something that happens when writing to
+the multi pass data file. It can also be used for overloading, for instance in
+the backend or when converting something. This protection against expansion has
+always been a \CONTEXT\ feature, which in turn made it pretty robust in multi
+pass scenarios, but it definitely came with performance penalty.
+
+When \PDFTEX\ got the \ETEX\ extensions we could use the \type {\protected}
+prefix to replace this trickery. That means that \MKII\ will use a different
+definition of \type {\doifelse} when that primitive is known:
+
+\starttyping
+\long\def\doifelse#1#2%
+  {\edef\!!stringa{#1}%
+   \edef\!!stringb{#2}%
+   \ifx\!!stringa\!!stringb
+     \expandafter\firstoftwoarguments
+   \else
+     \expandafter\secondoftwoarguments
+   \fi}
+\stoptyping
+
+This works okay because we now do this:
+
+\starttyping
+\protected\def\usedfoo{something is done here}
+\stoptyping
+
+The \type {\doifelse} helper itself is not protected in \MKII\ (non \ETEX\ mode)
+It would be a performance hit. I won't bore the reader with the tricks needed to
+do the opposite, that is: expand a protected macro. It is seldom needed anyway.
+
+The \MKIV\ definition used with \LUATEX\ is not much different, only the \type
+{\long} prefix is missing. That one is needed when one wants \type {#1} and|/|or
+\type {#2} to be tolerant with respect to embedded \type {\par} equivalents. In
+\LUAMETATEX\ we can disable that check and in \CONTEXT\ all macros are thereby
+\type {\long}. Users won't notice because in \CONTEXT\ most macros were always
+defined the long way; we also suppress \type {\outer} errors.
+
+\starttyping
+\protected\def\doifelse#1#2%
+  {\edef\m_syst_string_one{#1}%
+   \edef\m_syst_string_two{#2}%
+   \ifx\m_syst_string_one\m_syst_string_two
+     \expandafter\firstoftwoarguments
+   \else
+     \expandafter\secondoftwoarguments
+   \fi}
+\stoptyping
+
+Implementation wise a macro, once scanned and stored, carries the long property
+in its command code so that has overhead. However because \LUATEX\ is compatible
+we cannot make all normal macros long by default when \type {\suppresslongerror}
+is used. Therefore checking for an argument running into a \type {\par} is still
+checked but the message is suppressed based on the setting of the mentioned
+parameter. Performance wise, not using \type {\long} comes a the cost of checking
+a parameter which means an additional memory access and comparison. Unless we
+otherwise gain something in the engine it comes at a cost. In \LUAMETATEX\ the
+\type {\long} and \type {\outer} prefixes are ignored. Even better, protected
+macros are also implemented a bit more efficiently.
+
+In the end the definition of \type {\doifelse} in \LMTX\ looks a bit different:
+
+\starttyping
+\permanent\protected\def\doifelse#1#2%
+  {\iftok{#1}{#2}%
+     \expandafter\firstoftwoarguments
+   \else
+     \expandafter\secondoftwoarguments
+   \fi}
+\stoptyping
+
+The \typ {\permanent} prefix flags this macro as such. Depending on the value of
+\typ {\overloadmode} a redefinition is permitted, comes with a warning or
+results in a fatal error. Of course this comes at a price when we define macros
+or values of quantities but this is rather well compensated by all kind of
+improvements in handling macros: defining, expansion, saving and restoring, etc.
+
+More interesting is the use of \type {\iftok} here. It saves us defining two
+helper macros. Of course the content still needs to be expanded before comparison
+but we no longer have various macro management overhead. In scenarios where we
+don't need to jump over the \type {\else} or \type {\fi} we can use this test in
+place which saves passing two arguments and grabbing one argument later on.
+Actually, grabbing is also different, compare:
+
+\starttyping
+          \def\firstoftwoarguments #1#2{#1} % MkII and MkIV
+\permanent\def\firstoftwoarguments #1#-{#1} % MkXL aka LMTX
+
+          \def\secondoftwoarguments#1#2{#1} % MkII and MkIV
+\permanent\def\secondoftwoarguments#-#1{#1} % MkXL aka LMTX
+\stoptyping
+
+In the case of \LUAMETATEX\ the \type {#-} makes that we don't even bother to
+store the argument as it is ignored. Where \type {#0} does the same it also
+increments the argument counter which is why here even the second arguments has
+number ~1. Now, if this more efficient? Sure, but how often does it really
+happen? The engine still needs to scan (which comes at a cost) but we save on
+temporary token list storage. Because \TEX\ is so fast already, measuring only
+shows differences when one has many (and here a real lot) iterations. However,
+all these small bits add up which is what we've seen in 2022 in \CONTEXT: it is
+the reason why we are now faster than \MKIV\ with \LUATEX, even with more
+functionality in the engine.
+
+I can probably write hundreds of pages in explaining what was added, changed,
+made more flexible and what side effects it had|/|has on performance but I bet no
+one is really interested in that. In fact, the previous exploration is just a
+side effect of a question that triggered it, so maybe future questions will
+trigger more explanations. It anyhow demonstrates what I meant when I said that
+\LUAMETATEX\ is meant to be leaner and meaner. Of course the code base and binary
+is smaller but that also gets compensated by more functionality. It also means
+that we can make the \CONTEXT\ code base nicer because for me a good looking
+source (which of course is subjective) is pretty important.
+
+\stopsection
+
+\startsection[title=Compatibility]
+
+There are non \CONTEXT\ users who seem to love to stress that successive versions
+of \CONTEXT\ are incompatible. Other claims are that it is developed in a
+commercial setting. While it is true that there are changes and it is also true
+that \CONTEXT\ is used in commercial settings, it is not that different from
+other open source projects. The majority of the code is written without
+compensation and it is offered without advertisements or request for support. It
+is true that when we can render better, it will be done. But the user interfaces
+only change when there is a reason and there are few cases where some
+functionality became obsolete, think of input and font encodings. Most such
+changes directly relate to the engine: in \PDFTEX\ and \MKII\ we emulate \UTF-8\
+wile in \LUATEX\ is comes natively. In \PDFTEX\ eight bit (\TYPEONE) fonts are
+used while \LUATEX\ adds support for \OPENTYPE. Other macro packages support that
+by additional packages while \CONTEXT\ has it integrated. That is why the system
+evolves over time.
+
+Just a users adapt to (yearly) operating system interfaces, mobile phones, all
+kinds of hardware, cars, clothing, media and so on, the \CONTEXT\ users have no
+problem adapting to an evolving \TEX\ ecosystem. I guess claims about changes
+(being a disadvantage) can only point to a lack of development elsewhere. The
+main reason for mentioning this is that when \CONTEXT\ users move on to newer
+engines, the older ones are seldom used. So, few users compare a \LMTX\ run with
+one using \PDFTEX\ or \LUATEX. They naturally expect \LUAMETATEX\ to perform well
+and maybe even to perform better over time. They just don't complain. And unless
+one hacks (overloads) system macros compatibility is not really an issue. What
+can be an issue is that updates and adaptations to a newer engine come with bugs
+but those are solved.
+
+So, the fact that we compare incompatible engines with likely different low level
+macro implementations of otherwise stable features of a macro package makes
+comparison hard. For instance, maybe there are speedups possible in frozen \MKII,
+although it is unlikely, which makes that it might even perform better than
+reported. In a similar fashion, the fact that \OPENTYPE\ is more demanding for
+sure makes that \LUATEX\ rendering is slower than \PDFTEX. It anyhow makes a
+discussion about performance within and between macro packages even more
+ridiculous. Just don't buy those claims and|/|or ask on the \CONTEXT\ mailing
+list for clarification.
+
+\stopsection
+
+\startsection[title=The job]
+
+So, say that we now have an efficient and powerful engine and a matching macro
+package. Does that make all jobs faster? For sure, the ones that I use as
+benchmark run much smoother. The 360 page \LUAMETATEX\ manual runs in less than
+8.4 seconds on a Dell Precision laptop with (mobile) Intel(R) Xeon(R) CPU
+E3-1505M v6 @ 3.00GHz, 2TB fast Samsung pro SSD, and 48 GB of memory, running
+Windows 10. The \METAFUN\ manual with many more pages and thousands of \METAPOST\
+graphics needs a bit more than 12 seconds. So you don't hear me complain. This
+chapter takes 7.5 seconds plus 0.5 is for the runner, not enough time to get
+coffee.
+
+Nowadays I tend to measure performance in terms of pages per second, because in
+the end that is what users experience. For me more important are the gains for my
+colleague who processes documents of 400 pages from hundreds of small \XML\ files
+with multiple graphics per page. Given different output variants a lot of
+processing takes place, so there a gain from 20 pages per second to 25 pages per
+second is welcome. Anyway, here are a few measurements of a {\em simple} test suite
+per January 7, 2023. We use this as test text:
+
+\starttyping
+\def\Knuth{%%
+Thus, I came to the conclusion that the designer of a new system
+must not only be the implementer and first large||scale user; the
+designer should also write the first user manual.
+\par
+The separation of any of these four components would have hurt
+\TeX\ significantly. If I had not participated fully in all these
+activities, literally hundreds of improvements would never have
+been made, because I would never have thought of them or perceived
+why they were important.
+\par
+But a system cannot be successful if it is too strongly influenced
+by a single person. Once the initial design is complete and fairly
+robust, the real test begins as people with many different
+viewpoints undertake their own experiments.
+}
+\stoptyping
+
+Now keep in mind that these are simple examples. On more complex documents the
+\LUAMETATEX\ engine with \LMTX\ is relatively faster: think \XML, plenty
+\METAPOST, complex tables, advanced math, dozens of fonts in combination with the
+new compact font mode.
+
+The tests themselves are simple: we switch fonts (because fonts bring overhead),
+we add some color (because we use different methods), we process some graphics
+(to show what embedding \METAPOST\ brings), we do some tables (because that can
+be stressful). Each sample is run 50, 500 or 1000 times, and each set is run a
+couple of times so that we compensate for caching and fluctuating system load.
+The tests are more about signaling a trend than about absolute numbers. For
+what it's worth, I used a \LUA\ script to run the samples.
+
+When you run an experiment that measures performance, keep in mind that
+performance not only depends on the engine, but also on for instance logging.
+When I run the \CONTEXT\ test suite it takes 1250 seconds if the console takes
+the full screen on a 2560 by 1600 display and 30 seconds more on a 3840 by 2160
+display and it even depends on how large the font is set. On the 1920 by 1200
+monitor I get to 1230. Of course these times change when we add more to the test
+suite so it's always a momentary measurement.
+
+Similar differences can be observed when running in an editor. A good test is
+making a \CONTEXT\ format: 2.2 seconds goes down to below 1.8 when the output is
+piped to a file. On a decent 2023 desktop those times are probably half but I
+don't have one at hand.
+
+\startsubsubject[title={sample 1, number of runs: 2}]
+
+\starttyping
+\starttext
+    \dorecurse {%s} {
+        \Knuth
+        \par
+    }
+\stoptext
+\stoptyping
+
+\starttabulate[||r|r|r|]
+\HL
+\BC engine \BC 50 \BC 500 \BC 1000 \NC \NR
+\HL
+\BC pdftex     \NC 0.63 \NC 0.83 \NC 1.07 \NC \NR
+\BC luatex     \NC 0.95 \NC 1.86 \NC 2.94 \NC \NR
+\BC luametatex \NC 0.61 \NC 1.49 \NC 2.48 \NC \NR
+\HL
+\stoptabulate
+
+\stopsubsubject
+
+\startsubsubject[title={sample 2, number of runs: 2}]
+
+\starttyping
+\starttext
+    \dorecurse {%s} {
+        \tf \Knuth \bf \Knuth
+        \it \Knuth \bs \Knuth
+        \par
+    }
+\stoptext
+\stoptyping
+
+\starttabulate[||r|r|r|]
+\HL
+\BC engine \BC 50 \BC 500 \BC 1000 \NC \NR
+\HL
+\BC pdftex     \NC 0.70 \NC 1.73 \NC 2.80 \NC \NR
+\BC luatex     \NC 1.37 \NC 5.37 \NC 9.92 \NC \NR
+\BC luametatex \NC 1.04 \NC 5.06 \NC 9.73 \NC \NR
+\HL
+\stoptabulate
+
+\stopsubsubject
+
+\startsubsubject[title={sample 3, number of runs: 2}]
+
+\starttyping
+\starttext
+    \dorecurse {%s} {
+        \tf \Knuth \it knuth \bf \Knuth \bs knuth
+        \it \Knuth \tf knuth \bs \Knuth \bf knuth
+        \par
+    }
+\stoptext
+\stoptyping
+
+\starttabulate[||r|r|r|]
+\HL
+\BC engine \BC 50 \BC 500 \BC 1000 \NC \NR
+\HL
+\BC pdftex     \NC 0.71 \NC 1.81 \NC 2.98 \NC \NR
+\BC luatex     \NC 1.41 \NC 5.84 \NC 10.77 \NC \NR
+\BC luametatex \NC 1.05 \NC 5.71 \NC 10.60 \NC \NR
+\HL
+\stoptabulate
+
+\stopsubsubject
+
+\startsubsubject[title={sample 4, number of runs: 2}]
+
+\starttyping
+\setupcolors[state=start]
+\starttext
+    \dorecurse {%s} {
+        {\red \tf \Knuth \green \it knuth}
+        {\red \bf \Knuth \green \bs knuth}
+        {\red \it \Knuth \green \tf knuth}
+        {\red \bs \Knuth \green \bf knuth}
+        \par
+    }
+\stoptext
+\stoptyping
+
+\starttabulate[||r|r|r|]
+\HL
+\BC engine \BC 50 \BC 500 \BC 1000 \NC \NR
+\HL
+\BC pdftex     \NC 0.73 \NC 1.91 \NC 3.64 \NC \NR
+\BC luatex     \NC 1.39 \NC 5.82 \NC 12.58 \NC \NR
+\BC luametatex \NC 1.07 \NC 5.57 \NC 11.85 \NC \NR
+\HL
+\stoptabulate
+
+\stopsubsubject
+
+\startsubsubject[title={sample 5, number of runs: 2}]
+
+\starttyping
+\starttext
+    \dorecurse {%s} {
+        \null \page
+    }
+\stoptext
+\stoptyping
+
+\starttabulate[||r|r|r|]
+\HL
+\BC engine \BC 50 \BC 500 \BC 1000 \NC \NR
+\HL
+\BC pdftex     \NC 0.62 \NC 1.12 \NC 1.68 \NC \NR
+\BC luatex     \NC 0.90 \NC 1.39 \NC 1.98 \NC \NR
+\BC luametatex \NC 0.58 \NC 0.99 \NC 1.46 \NC \NR
+\HL
+\stoptabulate
+
+\stopsubsubject
+
+\startsubsubject[title={sample 6, number of runs: 2}]
+
+\starttyping
+\starttext
+    \dorecurse {%s} {
+        %% nothing
+    }
+\stoptext
+\stoptyping
+
+\starttabulate[||r|r|r|]
+\HL
+\BC engine \BC 50 \BC 500 \BC 1000 \NC \NR
+\HL
+\BC pdftex     \NC 0.55 \NC 0.54 \NC 0.56 \NC \NR
+\BC luatex     \NC 0.79 \NC 0.81 \NC 0.82 \NC \NR
+\BC luametatex \NC 0.54 \NC 0.52 \NC 0.53 \NC \NR
+\HL
+\stoptabulate
+
+\stopsubsubject
+
+\startsubsubject[title={sample 7, number of runs: 2}]
+
+\starttyping
+\starttext
+    \dontleavehmode
+    \dorecurse {%s} {
+        \framed[width=1cm,height=1cm,offset=2mm]{x}
+    }
+\stoptext
+\stoptyping
+
+\starttabulate[||r|r|r|]
+\HL
+\BC engine \BC 50 \BC 500 \BC 1000 \NC \NR
+\HL
+\BC pdftex     \NC 0.58 \NC 0.65 \NC 0.71 \NC \NR
+\BC luatex     \NC 0.84 \NC 0.96 \NC 1.08 \NC \NR
+\BC luametatex \NC 0.54 \NC 0.62 \NC 0.72 \NC \NR
+\HL
+\stoptabulate
+
+\stopsubsubject
+
+\startsubsubject[title={sample 8, number of runs: 2}]
+
+\starttyping
+\starttext
+    \dontleavehmode
+    \dorecurse {%s} {
+        \framed
+          [width=1cm,height=1cm,offset=2mm,
+           foregroundstyle=bold,foregroundcolor=red,
+           background=color,backgroundcolor=green]
+          {x}
+    }
+\stoptext
+\stoptyping
+
+\starttabulate[||r|r|r|]
+\HL
+\BC engine \BC 50 \BC 500 \BC 1000 \NC \NR
+\HL
+\BC pdftex     \NC 0.59 \NC 0.70 \NC 0.83 \NC \NR
+\BC luatex     \NC 0.87 \NC 1.00 \NC 1.17 \NC \NR
+\BC luametatex \NC 0.55 \NC 0.66 \NC 0.78 \NC \NR
+\HL
+\stoptabulate
+
+\stopsubsubject
+
+\startsubsubject[title={sample 9, number of runs: 2}]
+
+\starttyping
+\starttext
+    \ifdefined\permanent\else\def\BC{\NC\bf}\fi
+    \dontleavehmode
+    \dorecurse {%s} {
+        \starttabulate[|||||]
+            \NC test \BC test \NC test \NC test \NC \NR
+            \NC test \BC test \NC test \NC test \NC \NR
+            \NC test \BC test \NC test \NC test \NC \NR
+            \NC test \BC test \NC test \NC test \NC \NR
+        \stoptabulate
+    }
+\stoptext
+\stoptyping
+
+\starttabulate[||r|r|r|]
+\HL
+\BC engine \BC 50 \BC 500 \BC 1000 \NC \NR
+\HL
+\BC pdftex     \NC 0.62 \NC 1.15 \NC 1.71 \NC \NR
+\BC luatex     \NC 0.94 \NC 1.84 \NC 2.86 \NC \NR
+\BC luametatex \NC 0.60 \NC 1.19 \NC 1.88 \NC \NR
+\HL
+\stoptabulate
+
+\stopsubsubject
+
+\startsubsubject[title={sample 10, number of runs: 2}]
+
+\starttyping
+\starttext
+    \dontleavehmode
+    \dorecurse {%s} {
+        \startMPcode
+            fill fullcircle scaled 1cm withcolor red ;
+            fill fullsquare scaled 1cm withcolor green ;
+        \stopMPcode
+        \space
+    }
+\stoptext
+\stoptyping
+
+\starttabulate[||r|r|r|]
+\HL
+\BC engine \BC 50 \BC 500 \BC 1000 \NC \NR
+\HL
+\BC pdftex     \NC 5.73 \NC 50.98 \NC 102.10 \NC \NR
+\BC luatex     \NC 0.93 \NC 1.07 \NC 1.30 \NC \NR
+\BC luametatex \NC 0.57 \NC 0.71 \NC 0.86 \NC \NR
+\HL
+\stoptabulate
+
+\stopsection
+
+\startsection[title=Final words]
+
+Whenever I run into (or get send) remarks of (especially non \CONTEXT) users
+suggesting that \LUATEX\ is much slower than \PDFTEX\ or that \LUAMETATEX\ seems
+much faster than \LUATEX, one really has to keep in mind that this is not always
+true. Among the questions to be asked are \quotation {What engine do you use?},
+\quotation {Which macro package do you use?}, \quotation {How well is your style
+set up?}, \quotation {How complex is the document?}, \quotation {Is your own
+additional code efficient?}, \quotation {Do you use engine and macro package
+features the right way?} and of course \quotation {What do you compare with?},
+\quotation {What do you expect and why?}, \quotation {Do you actually know what
+goes on deep down?}. An embarrassing one can be \quotation {Do you have an idea
+what is involved in fulfilling your request given that we use a flexible adaptive
+macro language?}. Much probably these questions not get answered properly.
+
+Another thing to make clear is that when someone claims for instance that
+\CONTEXT\ \LMTX\ is fast because of \LUAMETATEX, or that \LUAMETATEX\ is much
+faster than \LUATEX, a healthy suspicion should kick in: does that someone really
+knows what happens and matters? The previous numbers do show differences for
+simple cases but we're often not talking of differences that can be used as an
+excuse for insufficient coding. In the end it is all about the experience: does
+performance feel in tune with expectations. Which is not to say that I will make
+\CONTEXT\ and \LUAMETATEX\ faster because after all there are usage scenarios
+where one has to process tens of thousands of documents with a reasonable amount
+of time, on regular infrastructure, and of course with as little as possible
+energy consumption.
+
+If \PDFTEX\ suits your purpose, there is no need to move to \LUATEX. As with
+rechargeable batteries in cordless phones a higher capacity can make things
+worse. If \LUATEX\ fits the bill, don't dream about using \LUAMETATEX\ instead
+because it will half runtime because the adaptations needed in the macro package
+(like adding a backend) might actually slow it down. Moores law doesn't apply to
+\TEX\ engines and macro packages and you might get disappointed. Accept that the
+choice you made for a macro package can come with a price.
+
+Quite often it is rather easy to debunk complaints and claims which makes one
+wonder why claims about perceived or potential are made at all. But then, I'm
+accustomed to weird remarks and conclusions about \CONTEXT\ as a macro package,
+or for that matter \LUATEX\ (as it originates in the \CONTEXT\ community) even by
+people who should know better. Hopefully the above invites to being more careful.
+
+\stopsection
+
+\stopchapter
+
+\stopcomponent
diff --git a/doc/context/sources/general/manuals/musings/musings.tex b/doc/context/sources/general/manuals/musings/musings.tex
index 143dfe456..3e3b35ea0 100644
--- a/doc/context/sources/general/manuals/musings/musings.tex
+++ b/doc/context/sources/general/manuals/musings/musings.tex
@@ -27,6 +27,7 @@
   % \component musings-treasures
   % \component musings-whytex-again
     \component musings-dontusetex
+  % \component musings-speed
 \stopbodymatter
 
 \stopproduct