Cfrgtkky

I frequently have the problem that I have to perform some simplistic calculations, mostly products and sums of two or three quantities. I used to use the fp package for it, but it does look somewhat unmaintained. Now I've tried pgfmath, and like everything coming from the TikZ direction it is outrageously complete, thoroughly documented, and has a nice API with a great syntax to top it off. And I'm using TikZ for graphics anyway, so there's no additional overhead in terms of packages used.

The only thing that worries me is performance. I could devise some tests to get a better idea of how fast pgfmath is in comparison, but I thought I'd better ask around first:

• are there any articles that compare different solutions to perform simple arithmetics in TeX




• that include benchmarks?




• What is the best practice when one wants to do multiplication of fractional, signed numbers? Neither precision nor magnitude have to be all that great, given that these numbers are used to do typesetting, so everything that is accurate to the tenth of a millimeter or so for dimensions up to several hundreds of millimeters should be fine.

As well as fp and the pgf maths parser, I think I would evaluate xfp/LaTeX3 FPU here. With a simple test set up such as

documentclass{article}

usepackage{fp}

usepackage{xfp}

usepackage{tikz}

usepackage{l3benchmark}

ExplSyntaxOn

cs_new_eq:NN benchmark benchmark:n

ExplSyntaxOff

FPmessagesfalse

newsavebox{testbox}

begin{document}

benchmark{sbox{testbox}{FPupnresult{2 2 root 40 sin *}}}

benchmark{sbox{testbox}{fpeval{sqrt(2) * sind(40)}}}

benchmark{sbox{testbox}{pgfmathparse{sqrt(2) * sin(40)}}}

end{document}

on my system I get

0.00556 seconds (2.03e4 ops)

5.06e-4 seconds (1.83e3 ops)

2.23e-4 seconds (819 ops)

Unsurprisingly, fp is slowest as it works to a huge number of places. On the other hand, the pgf unit is fastest but not by much over the LaTeX3 code. The pgf code is not expandable, and uses dimens internally, trading accuracy for speed. The latter is perfectly reasonable, but of course may or may not be acceptable depending on use case.

(For the test, I've used the UPN part of fp largely as it seems fairest: the other two options offer parsing of expressions ...)

For completeness, if you are using LuaTeX then you can do the same using Lua, which is very fast:

benchmark{sbox{testbox}{directlua{tex.print(math.sqrt(2) * math.sin(40))}}}

gives 5.1e-5 seconds (187 ops) seconds on my test setup.

Worth noting of course is that the speed does depend on the exact operation: if I go for a simple sum, pgf and the LaTeX3 FPU are comparable:

documentclass{article}

usepackage{fp}

usepackage{xfp}

usepackage{tikz}

usepackage{l3benchmark}

ExplSyntaxOn

cs_new_eq:NN benchmark benchmark:n

ExplSyntaxOff

FPmessagesfalse

newsavebox{testbox}

begin{document}

benchmark{sbox{testbox}{FPupnresult{1.234 5 * 9.10 6.78 / +}}}

benchmark{sbox{testbox}{fpeval{1.234 * 5 + 6.78 / 9.10}}}

benchmark{sbox{testbox}{pgfmathparse{1.234 * 5 + 6.78 / 9.10}}}

end{document}

gives

0.00231 seconds (8.42e3 ops)

2.25e-4 seconds (837 ops)

2.63e-4 seconds (930 ops)

If you want simple dimension calculations, nothing is going to beat primitive, most obviously dimexpr. Something like

thedimexpr 1.2cm + 3.445cmrelax

is 'clocked' by the benchmark code at 2.64e-6 seconds (9.85 ops) on my system: really, really fast.

tl;dr: pgfmath is 10 Times faster than fp

So I went and did a little test that I feel is sufficiently realistic for my intended purpose: typesetting dozens and hundred of pages with like a dozen floating point multiplications per page.

With around 80 pages of typesetting material my test document needed roughly a1 = 6 seconds to complete typesetting with XeLaTeX using pgfmath; with three times as much stuff, that rose to b1 = 13 seconds. In comparison, doing the same using fp, the timings came out as a2 = 37 and b2 = 107 seconds. Clearly, there must be a certain overhead here, which I estimated using the assumption that ( a1 - c ) * 3 = b1 - c and ( a2 - c ) * 3 = b2 - c, giving me a constant overhead of around c = 2.5 seconds. Timings with that overhead subtracted, then, are a1c = 3.5, b1c = 10.5, a2c = 34.5, b2c = 104.5.

While these measurements are all done in a rough way and with lots of hand-waving, they still seem to indicate that fp takes ten times as long as pgfmath.

There's still all kinds of wiggle room in here; I haven't checked whether the fp calculations couldn't have been optimized (which could narrow the gap), and I did not use the short-circuited versions of pgfmathparse and friends (which could widen the gap), but, on the other hand, a 1 / 10 ratio is unlikely to be easily done away with.

I haven't done tests with xfp / LaTeX3 FPU yet, as suggested by Joseph Wright; I did look up that stuff on CTAN and it does look very promising with regard to the future of LaTeX. It's really bleeding-edge and none of that is included in my TeX Live 2016 installation which I'm loath to update at this point in time. But certainly something to consider for the future.

My figures differ from those of Joseph Wright, so feel free to critique my methodology.