问题是文件越复杂,在内存中构建完整的DOM结构所需的时间就越长.与其他解析方法相比,创建DOM更慢且占用内存更多(通常整个DOM必须适合内存). XPath依赖于这个DOM.

SAX通常是人们为速度或不适合内存的大型文档而转向的.它更多的是事件驱动：它通知你一个start元素,end元素等,你编写处理程序来对它们作出反应.这有点痛苦,因为你最终会自己跟踪状态(比如你在哪个元素里面).

有一个中间立场：一些解析器具有“拉解析”功能,您可以在其中进行类似光标的导航.您仍然按顺序访问每个节点,但是您可以“快进”到您不感兴趣的元素的末尾.它具有SAX的速度,但是用于许多用途的更好的界面.我不知道Nokogiri是否可以为HTML做这个,但如果你有兴趣我会调查它的Reader API.

请注意,Nokogiri对格式错误的标记(例如真实HTML)也非常宽容,仅此一点就使它成为HTML解析的一个非常好的选择.