amsmath.dtx: Request to speed up \genfrac@choice

[RuixiZhang42]

Brief outline of the enhancement

For XeTeX/LuaTeX, the \genfrac command relies on \genfrac@choice to generate delimited fraction. But \genfrac@choice always makes a four-way choice, for each of the opening and closing delimiters (if they are present). Those are 8 tries for typesetting a single \binom{n}{k}. The same is true even when mathstyle is forced: \dbinom{n}{k} still requires 8 tries, and \tbinom still requires 8 tries, too.

When a mathstyle is forced, can we speed things up by avoiding \mathchoice?

Experimental code proposal

% XeTeX version proposal.
% \cs{genfrac@choice} now takes three arguments:
% \arg{1} opening/closing identifier, \arg{2} the delimiter,
% \arg{3} mathstyle override (the new one).
%    \begin{macrocode}
\def\genfrac@choice#1#2#3{%
\ifx @#2@\else
%    \end{macrocode}
% \changes{v2.17a}{2017/09/02}{move \cs{nulldelimiterspace} correction}
%    \begin{macrocode}
\ifx c#1\kern-\nulldelimiterspace\fi
{\delimitershortfall\z@\delimiterfactor\@m
 \mathsurround\z@\nulldelimiterspace\z@
%    \end{macrocode}
% \changes{...}{2020/11/..}{speed things up for mathstyle override}
%    \begin{macrocode}
\ifx\@empty#3\@empty
%    \end{macrocode}
% If there were no mathstyle override, we proceed with \cs{mathchoice}.
%    \begin{macrocode}
\mathchoice
{\genfrac@rule{#2}{20}\textfont{2.39}}%
{\genfrac@rule{#2}{21}\textfont{1.01}}%
{\genfrac@rule{#2}{21}\scriptfont{1.45}}%
{\genfrac@rule{#2}{21}\scriptscriptfont{1.35}}%
\else
%    \end{macrocode}
% Otherwise, we typeset the delimiter according to the mathstyle override.
% Note that there should be a space (or \cs{relax}) after |#3| to stop
% further expansion when TeX is scanning a ``number''.
%    \begin{macrocode}
\ifcase#3\relax
\genfrac@rule{#2}{20}\textfont{2.39}\or
\genfrac@rule{#2}{21}\textfont{1.01}\or
\genfrac@rule{#2}{21}\scriptfont{1.45}\else
\genfrac@rule{#2}{21}\scriptscriptfont{1.35}\fi
\fi
}%
\ifx o#1\kern-\nulldelimiterspace\fi
\fi
}
%    \end{macrocode}
% \changes{...}{2020/11/..}{speed things up for mathstyle override}
% Adapt to \cs{genfrac@choice} accordingly.
%    \begin{macrocode}
\DeclareRobustCommand{\genfrac}[6]{{%
\@mathstyle{#4}%
\genfrac@choice o{#1}{#4}%
{\begingroup#5\endgroup\ifx @#3@\@@over\else\@@above\fi#3\relax#6}%
\genfrac@choice c{#2}{#4}%
}}
%    \end{macrocode}

[FrankMittelbach]

@RuixiZhang42 I'm reluctant to do speed improvements in a case like this to be honest. The gain seems fairly small even in a document that is doing a lot of math. And one thing I learned is that even the simples internal change is breaking something somewhere along the line.

Now that doesn't mean would shouldn't do something and live with the consequences (eg finding the packages that break, talk to the maintainers get things adjusted, etc) but for me it means one should only do this if either a) it is a clear bug or b) it is a very substantial improvement in speed or c) a very strong case of normalization that helps a lot later on.

So far I'm not convinced the suggestion falls into either category, but perhaps this is seen differently by others.

[RuixiZhang42]

@FrankMittelbach This is understandable. I guess my request has more to do with the something like this:

% !TeX program = XeLaTeX
\documentclass{article}
\usepackage{amsmath}
\begin{document}
Here is a display with some text in it
\[
\dbinom{n}{k},\quad\text{where $\dbinom{n}{k}$ is defined by\dots}
\]
\end{document}

The inline math within the text within the display ends up being typeset 4×4 times (or 4×8 times if we count opening/closing parenthesis separately), compared with just 4 times for the text if \dbinom were efficient. Now, think about an application where each line of some binomial derivation is commented just like this :(

This XeTeX/LuaTeX version is based on engine, not on math fonts. Both XeTeX and LuaTeX can use TFM-based fonts, where the classical version of \genfrac would be just fine. Only OpenType math fonts need the new version’s help. I’m wondering if a font-dependent (not engine-dependent) solution is available.

[davidcarlisle]

This XeTeX/LuaTeX version is based on engine, not on math fonts.

I did wonder about that at the time, but that would mean a run-time check on every fraction whether the main math font had the needed parameters (I don't think either xetex or luatex have a simple built in boolean flag to say the classic or opentype math layout is being used) and would mean having both versions active and more code paths to check..

As this was something of an "emergency fix" at the time to get generalised fractions working for the AMS, having a simplified code path to test was more important than optimising the time. (You would have to have a lot of fractions before the time was noticeable in comparison to say how long unicode-math spends reading the unicode-math-table file.)

I suspect that this should be merged into the longish term xmath project see https://github.com/latex3/latex2e/projects to look at future improvements. That said, we do need to change something here to fix your previous issue #432 (which is a definite bug)

[FrankMittelbach]

@davidcarlisle do you think we can get to a conclusion here?

[FrankMittelbach]

ah, overlooked you already said parts of that. So can we "do something" with respect to #432 and move the resto to xmath?

[stale]

This issue has been automatically marked as stale because it has not had recent activity.