27

The LaTeX kernel defines a number of tokens that are used throughout the LaTeX source and the standard LaTeX classes. For example:

\def\hb@xt@{\hbox to}

This particular one is commented as:

The next one is another 100 tokens worth.

My understanding is that the tokens are saved by abbreviating the to and that is where the tokens are saved.

Similarly,

\@height saves 5 tokens at the cost in time of one macro expansion by defining the macro \def\@height{height} to replace the TeX height and so on with many more examples.

However, in many cases the conversion, in my opinion, makes the code difficult to read. With to-days's computer power, is this still a good practice? Would you recommend that one should optimize final code in such a manner?

lockstep
  • 250,273
yannisl
  • 117,160

3 Answers3

25

It was when the code was written, but is not now (in my opinion). The current LaTeX2e kernel was released in 1992 and carries forward a lot of material from LaTeX2.09. Even with these optimisations and the old 'autoload' system, there were a lot of systems that LaTeX was too big for on release. So looked at in the early 1990s this was entirely sensible.

I'd say this is no longer needed as in most LaTeX documents today there are a lot of tokens used by things like pgf which make the modest saving in optimisation pretty meaningless. One of the things we're doing in LaTeX3 is trying to move to more logical constructs at the expense of efficiency in tokens, at least at a higher level. (Right at the core of expl3 there is still a need to watch the number of expansions, etc., and this is an area where we may yet need some more optimisation.)

Caramdir
  • 89,023
  • 26
  • 255
  • 291
Joseph Wright
  • 259,911
  • 34
  • 706
  • 1,036
9

If you don't have an application that needs to be optimized as much as you can, then do whatever you can read best. The one second you gain in your lifetime by waiting for a document to be processed 0.0001 second faster each time opposes many minutes / hours? by looking for the right definitions of your "optimized" macro names. This is true for all programming languages / optimizations.

topskip
  • 37,020
  • 5
    The trouble with optimisation is, no matter how pressing the need, you can paint yourself into ugly corners when you have code written for efficiency rather than readability. Writing readable and efficient code - well, that's an art. plain.tex is a better source for that than the Latex2 sources. – Charles Stewart Dec 03 '10 at 12:24
  • 6
    Token shortcut optimizations like the one above do not necessarily make the file run any faster. There is extra runtime needed for defining the macro first and then, whenever the macro is actually expanded, it takes more time as well: starting to read from a new macro expansion is slower than just parsing a complete list. Such solutions are therefore only faster if the new macro is skipped over more often (during conditional processing and e.g. macro definitions) than that it is actually needed (for typesetting). – Taco Hoekwater Dec 03 '10 at 12:37
8

No.

I recall a former colleague, a Lisp hacker, who talked about when he switched from expressing pairs using (first . second) to (first second): the former needs two extra characters on the screen, the latter used an extra cons cell in the data representation. He changed when he realised he cared that little bit more about "screen estate" than data efficiency.

Charles Stewart
  • 21,014
  • 5
  • 65
  • 121