为什么sax解析比dom解析更快？ stax是如何工作的？
有点相关： 来自java的libxml2
是的，这个问题相当啰嗦 – 抱歉。 我保持尽可能密集。 我把这些问题加粗，以便在阅读整篇文章之前更容易窥视。
为什么sax解析比dom解析更快？ 我唯一能想到的就是w / sax你可能忽略了大部分传入数据，因此不会浪费时间处理你不关心的xml部分。 IOW – 解析w / SAX后，无法重新创建原始输入。 如果您编写了SAX解析器，以便它占据每个xml节点（并因此可以重新创建原始节点），那么它不会比DOM更快吗？
我问的原因是我正在尝试更快地解析xml文档。 我需要在解析后访问整个xml树。 我正在编写一个插入第三方服务的平台，所以我无法预测xml文档的哪些部分需要以及哪些部分不需要。 我甚至不知道传入文件的结构。 这就是为什么我不能使用jaxb或sax。 内存占用对我来说不是问题，因为xml文档很小，我一次只需要1个内存。 这是解析这个相对较小的xml文档所花费的时间。 我之前没有使用过stax，但也许我需要进一步调查，因为它可能是中间地带？ 如果我理解正确，stax会保留原始的xml结构并处理我要求的部分吗？ 通过这种方式，原始的解析时间可能很快，但每次我要求它遍历尚未遍历的树的一部分时，那就是处理发生的时间？
如果您提供了回答大多数问题的链接，我会接受您的回答（如果他们已经在其他地方得到回答，您不必直接回答我的问题）。
更新：我在sax中重写了它，并在avg 2.1 ms上解析文档。 这比dom所采用的2.5毫秒有所改善（快16％），但这并不是我（等人）猜到的那么大。
谢谢
假设除了解析文档之外什么都不做，不同解析器标准的排名如下：
1. StAX是最快的
- 该事件将报告给您
接下来是SAX
- 它完成了StAX所做的一切以及内容自动实现（元素名称，命名空间，属性……）
3. DOM是最后的
- 它完成SAX所做的一切，并将信息作为Node的实例呈现。
你的用例
- 如果需要维护所有XML，则DOM是标准表示。 它与XSLT转换（javax.xml.transform ），XPath（ javax.xml.xpath ）和模式validation（ javax.xml.validation ）API完全集成。 但是，如果性能是关键，那么您可以使用StAX构建自己的树结构，而不是DOM解析器可以构建DOM。
DOM解析要求您将整个文档加载到内存中，然后遍历树以查找所需的信息。
SAX只需要尽可能多的内存来执行基本IO，并且您可以在读取文档时提取所需的信息。 因为SAX是面向流的，所以您甚至可以处理仍由另一个进程写入的文件。
SAX更快，因为DOM解析器通常使用SAX解析器在内部解析文档，然后执行创建和操作对象以表示每个节点的额外工作，即使应用程序不关心它们。
直接使用SAX的应用程序可能比DOM“解析器”更有效地利用信息集。
StAX是一种快乐的媒介，其中应用程序获得比SAX的事件驱动方法更方便的API，但不会产生创建完整DOM的低效率。
SAX比DOM更快（通常在读取大型XML文档时感觉到），因为SAX会将信息作为一系列事件（通常通过处理程序访问）提供，而DOM创建节点并管理节点创建结构，直到完全创建DOM树（如在XML文档中表示）。
对于相对较小的文件，您将感觉不到效果（除了可能由DOM完成额外处理以创建节点元素和/或节点列表）。
我不能真正评论StAX，因为我从未玩过它。