AngleSharp 性能评估

一般考虑

该库并不小（但也不是很大），这使得预加载或 “预热”（或使用 NGen）成为生产使用的一个候选方案。首次运行总是会比后续运行慢，这是由于 C# / MSIL（或 JIT 过程）的性质，与 AngleSharp 无关。

AngleSharp 在设计时就考虑了性能。实际上，优先级如下：

1. 标准一致性
2. 性能
3. 辅助方法/扩展
4. 工具

尽管仍然有可能进行优化（因为首先必须确保所有功能正常工作，即已考虑到标准一致性），但性能是很有前景的。成熟的 Web 浏览器中的解析器（通常用 C/C++编写）的执行时间可能会更快，但对于完全托管的过程，整个解析/DOM 创建过程非常快。

接下来，AngleSharp 将与其他流行库进行比较，这些库要么非常流行（如 HtmlAgilityPack），要么雄心勃勃（如 CsQuery）。

与 Html Agility Pack 的比较

Html Agility Pack（HAP）是一个很好的比较目标，因为它被广泛使用并建立已久。显然，AngleSharp 是 HAP 的理想替代品，原因如下：

• 符合 HTML5 的标准化解析模型
• 更好的错误修正/处理
• 正确解析 SVG / MathML 元素
• 可以处理 CSS（选择器、规则等）
• 更好的性能

虽然前几点都很明显且明确（这也是开发 AngleSharp 的原因），但最后一点是有争议的。

为了证明这一点，编写了一个小型测试程序。以下代码片段代表了该程序的核心。

static async Task<Int64> Test(Func<String, Int64> test, String source)
{
    var min = Int64.MaxValue;

    for (int i = 0; i < 20; i++) {
        min = Math.Min(min, await Task.Run(() => test(source)));
    }

    return min;
}

static Int64 TestAngle(String source)
{
    var sw = Stopwatch.StartNew();
    var parser = new HtmlParser(source);
    parser.Parse();
    sw.Stop();
    return sw.ElapsedMilliseconds;
}

static Int64 TestAgility(String source)
{
    var sw = Stopwatch.StartNew();
    var document = new HtmlDocument();
    document.LoadHtml(source);
    sw.Stop();
    return sw.ElapsedMilliseconds;
}

然后，这个程序调用 Test 方法，传入多个网页的源代码。它们都相当重要/经常被使用，其中一些还相当大。最大的肯定是官方 W3C 语法规范。

以下图像显示了运行此测试的结果。（注意：所有包含的解析器的过时版本；仅用于说明）

请注意，我们取了 20 次试验中最低的墙时。如果取平均值，结果细节会有轻微变化，因为 AngleSharp 有更多的代码路径，因此在预热运行中需要更大的混合，但是总体结果仍然相同，AngleSharp 仍然更快。

HAP 在 “GoogleNews” 这一项上表现突出。然而，这是一种错误的印象。真正的加速来自于省略了（大的）内联样式表。在这里，AngleSharp 也需要解析 CSS，当然会花费一些额外的时间。下面的官方基准程序通过禁用 CSS 解析（因此只按预期基准 HTML 解析）来排除这种边缘情况。

与 CsQuery / validator.nu HTML 解析器的比较

CsQuery 项目的目标是成为 jQuery 的 C# 移植版。为了解析 HTML，选择了 validator.nu HTML5 引擎的移植版。因此，生成的 DOM 的有效性应该与 AngleSharp 大致相同，但缺少如 template 或 main 等重要元素。上面的图像还包括了 HTML 解析器的性能测量。

与 AngleSharp 相比，解析性能参差不齐。AngleSharp 是在早期阶段（v0.8.6）进行测量的，因此很可能 AngleSharp 的性能将进一步提高。尽管 CsQuery 项目雄心勃勃，包含了一些有趣的想法和特性，但 AngleSharp 试图从另一个角度解决问题——首先遵循标准，然后再添加一些不错的特性。过去的经验表明，先实现花哨的特性或非标准但更好的 API，后期会出现问题。

总的来说，有些情况下 AngleSharp 表现更好，有些情况下 validator.nu 解析器更快。在大多数情况下，赢家并没有真正关系（例如 2 毫秒对 3 毫秒）。

与其他解决方案的比较

也可以与其他项目进行比较。在官方的Performance项目（包含在 Visual Studio 解决方案中），你会发现Majestic（Majestic 13）解析器。这个解析器几乎总是比其他任何解决方案都快。它是你项目的正确选择吗？可能不是。原因很简单：Majestic 不构建 DOM，也不关心特殊标签、意义和 HTML 错误修正。基本上，Majestic 是 AngleSharp 减少到其词法分析器，词法分析器稍简单一些。

这也是将 Majestic 从性能比较中排除的原因。然而，出于个人乐趣，你当然可以再次包括 Majestic。代码已经检入。

当前性能

性能很重要，尽管标准一致性更重要。AngleSharp 的存储库带有一组基准测试。

HTML 解析器

这次测试的设置如下：

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19042
AMD Ryzen 7 2700X, 1 CPU, 16 logical and 8 physical cores
  [Host]   : .NET Framework 4.8 (4.8.4341.0), X64 RyuJIT
  ShortRun : .NET Framework 4.8 (4.8.4341.0), X64 RyuJIT

Job=ShortRun  IterationCount=3  LaunchCount=1
WarmupCount=3

结果如下所示。

DOM 查询/CSS 选择器

这次测试的设置如下：

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19042
AMD Ryzen 7 2700X, 1 CPU, 16 logical and 8 physical cores
  [Host]   : .NET Framework 4.8 (4.8.4341.0), X64 RyuJIT
  ShortRun : .NET Framework 4.8 (4.8.4341.0), X64 RyuJIT

Job=ShortRun  IterationCount=3  LaunchCount=1
WarmupCount=3

结果如下所示。