Pod::Parser 使用说明

2000年5月20日，作者：Brad Appleton

我的同事中有人注意到了p5p每周总结中关于（其他事情中）Pod::Parser的讨论。他们向我提到了这件事，并表示他们认为这让我显得不那么好。因此，我想澄清一些可能在总结中被遗漏或误解的内容……

我坦白承认对Pod::Parser的性能优化尝试非常少。（我之前在p5p和pod-people上提过这个问题，并寻求帮助过）。我当然同意Mark提出的许多关于POD格式的观点。但我想强调，Pod::Parser的大部分缓慢并不是由于POD格式本身，而是与创建一个灵活且可扩展的面向对象框架有关，以满足一般pod解析的需求（而不仅仅是将POD转换为其他输出格式的特定任务）。

Pod::Parser的大部分开销来自逐行解析（以跟踪行号并提供更好的诊断）和提供处理流程中的多个回调和“钩子”方法。由于Pod::Parser使用面向对象方法提供大量行、文件和命令/序列级别的预/后处理钩子，因此方法查找解析的开销相当高。（实际上，我敢打赌，至少可以通过在运行时预先计算一次来优化方法查找，实现至少10倍的性能提升。）

关于将185X作为podselect（使用Pod::Select，它又使用Pod::Parser :-）的预期性能目标的问题，请认识到podselect的目的是要做很多事情，而不仅仅是Tom的精简POD转储脚本所做的那样。碰巧的是，如果podselect没有给定任何参数，它也会执行这项相同的任务。但它的真正存在的原因是根据用户指定的匹配标准选择要输出的POD的特定部分。这是Pod::Usage所采用的，以便只格式化POD中与使用消息相关的部分。

当我在p5p上的这个帖子中提到podselect时，我只是指出现有的代码——已经设计成具有可重用钩子的代码——可以完成相同的功能性任务——我并没有意图宣称它的性能可以与之相比。我认为“185X”这个数字对于Pod::Parser来说是不合理的。不仅Pod::Parser需要做更多的解析，而且大部分开销来自于实现更好的诊断和可扩展性，这超出了Tom的脚本为一个非常特定且有限的目的所实现的功能。

对于目的仅限于特定事物的某物来说，185X可能是一个合理的基准，但我认为对于像Pod::Parser这样具有更广泛范围、适用性和用途的东西来说，则不然。虽然速度提升仍然需要，但我认为50X的改进是一个更合理的基准，并且我认为这是在合理可能的范围内。

在另一个地方——我认为总结可能遗漏了我对p5p关于Pod::Parser“输出”结构的回复。“输出”不仅仅是输出标签或线性流，如果你要求它，它还会输出解析树。

我同意需要有一个模块来强加更多的结构，但认为Pod::Parser必须以某种方式成为执行此操作的模块，这是一种误解。我认为Pod::Parser被故意创建为一个灵活的框架，以供构建，并且没有任何阻止某人创建一个在Pod::Parser之上的模块来执行所有这些更棒的事情。

但是，如果将“更优美”的功能添加到 Pod::Parser 中，将会破坏大量现有的代码——因为 Pod::Parser 不仅用于转换到其他输出格式。我在 p5p 和其他地方多次建议创建一个 Pod::Compiler 或 Pod::Translator 来强制执行这种增加的结构（现有的 Pod::Checker 模块可能是一个不错的起点）。

此外，摘要建议 Pod::Parser 和 Russ 的 POD 模块“已经开发了多年。”我认为可能 Mark 意思是各种与 POD 相关的解析和翻译/格式化模块已经开发了多年。特别是，我相信 Russ 只在去年刚刚开始他的“pod-lators”模块。

Pod::Parser 的开发开始得更早，但它的“孕育期”只有大约 6 个月，然后就有了一个有用且可工作的版本。从那时起，我在过去 2-3 年中进行了错误修复和增强。主要的功能增加是添加了解析树的能力（以及 pod “东西”的测试套件的开发，这来得太晚了 :-）。它直到 v5.6 版本才成为核心 Perl 分发的一部分，因为必须等待一些好心人（如 Russ）花费时间重写最常用的 pod2xxx 模块，以便使用 Pod::Parser 中提供的相同基本解析代码。

现在——我并不声称 Pod::Parser 是完美的——但我感觉摘要遗漏了一些重要的观点，这些观点可以为讨论增添更多的平衡。Pod::Parser 是否可以更快？当然可以！它是否可以快得多？当然可以。在我看来，它是否对最常见的用途来说不可用？一点也不是。它是否在处理大量 POD 时不可用？很可能。但正如我说的，这并不是因为 POD，而是因为需要内置的灵活性。

至少现在有一个共同的 POD 解析代码库，我们可以集中我们的集体优化努力，而不是来自不同 pod2xxx 模块的大量解析引擎。现在它已包含在核心中，也许这将鼓励更多的人专注于优化常见的 POD 解析器（我已经想得到帮助多年了 :-)）

-- 
Brad Appleton <[email protected]>  http://www.bradapp.net/
  "And miles to go before I sleep." -- Robert Frost