LaTeX 内核定义了许多在整个 LaTeX 源和标准 LaTeX 类中使用的标记。例如：
\def\hb@xt@{\hbox to}
对此特别的评论是：
下一个是另外价值 100 个代币。
我的理解是，通过缩写来保存标记to，这就是保存标记的地方。
相似地，
\@height\def\@height{height}通过定义宏来用更多示例替换 TeXheight等，以一次宏扩展的时间为代价节省了 5 个标记。
然而，在我看来，在很多情况下，这种转换会使代码难以阅读。以当今的计算机能力，这仍然是一种好的做法吗？你会建议以这种方式优化最终代码吗？
答案1
代码编写时是这样的，但现在不是了（在我看来）。当前的 LaTeX2e 内核于 1992 年发布，继承了 LaTeX2.09 的很多内容。即使有了这些优化和旧的“自动加载”系统，仍然有很多系统在发布时 LaTeX 太大了。因此，从 20 世纪 90 年代初期来看，这是完全合理的。
我认为这已不再需要，因为如今大多数 LaTeX 文档中都有很多标记，例如，pgf这使得优化中的适度节省变得毫无意义。我们在 LaTeX3 中所做的一件事是尝试转向更合乎逻辑的构造，至少在更高层次上以牺牲标记效率为代价。（核心在于expl3仍然需要关注扩展的数量，ETC.，这是一个我们可能还需要进一步优化的领域。）
答案2
如果您没有需要尽可能优化的应用程序，那么请尽您所能。通过每次等待文档处理速度快 0.0001 秒，您一生中节省的一秒钟与通过查找“优化”宏名称的正确定义节省的几分钟/小时形成鲜明对比。这适用于所有编程语言/优化。
答案3
不。
我记得一位前同事，一位 Lisp 黑客，他谈到当他从使用 表达对切换到 时(first . second)：(first second)前者需要在屏幕上显示两个额外的字符，后者在数据表示中使用了一个额外的 cons 单元。当他意识到自己更关心“屏幕空间”而不是数据效率时，他改变了主意。