Performance Evaluations

General Considerations

The library is not small (it's not huge either), which makes preloading or "warming-up" (or using NGen) a candidate for productive usage. The first runs will always be slower than the following. This is a property of C# / the MSIL (or the JIT process in general), which has nothing to do with AngleSharp.

AngleSharp has been written with performance in mind. Actually the priority is:

1. Standard conformance
2. Performance
3. Helpers / extensions
4. Tooling

Even though there are still optimizations possible (since everything had to be working first, i.e. standard conformance has been considered), the performance is promising. Parsers in established web browsers (usually written in C/C++) will still have a faster execution time, but for a completely managed process the whole parsing / DOM creation procedure is very fast.

In the following AngleSharp will be compared to other popular libraries, which are either very popular (like the HtmlAgilityPack) or ambitious (like CsQuery).

Comparison with the Html Agility Pack

The Html Agility Pack (HAP) is a good comparison target, since it is most used and established since a long time. Obviously AngleSharp is a great replacement for HAP due to the following reasons:

• Standardized HTML5 parsing model
• Much better error correction / handling
• Also parses SVG / MathML elements correctly
• Can handle CSS (selectors, rules, ...)
• Better performance

While the first points are all quite obvious and clear (that is why AngleSharp has been developed in the first place), the last point is controversial.

To proof this point a small test program has been written. The following code snippet represents the kernel of this program.

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;
}

This program then calls the Test method with the source code of several webpages. All of them are quite important / used very often and some of them are quite big. The biggest is definitely the official W3C syntax specification.

The following image shows the outcome of running this test. (caution: Outdated versions of all included parser; just for illustration)

Note that we took the lowest wall-time in 20 trials. The outcome details change slightly if we take the average - since AngleSharp has more code-paths and therefore requires a greater mix in warm-up runs than the HAP, however, the overall outcome is still the same with AngleSharp being faster.

The only entry where HAP excels is "GoogleNews". This is, however, a false impression. The true speedup comes from omitting the (large) inline style-sheet. Here AngleSharp has to parse CSS as well, which of course takes some additional time. The official benchmark program below excludes such edge cases by disabling CSS parsing (therefore only HTML parsing is benchmarked as intended).

Comparison with CsQuery / validator.nu HTML Parser

The CsQuery project aims to be a C# port of jQuery. To parse HTML a port of the validator.nu HTML5 engine has been selected. The validity of the resulting DOM should therefore on roughly the same level as AngleSharp, however, missing important elements such as template or main. The above image also includes the performance measurement for the HTML parser.

The parsing performance is mixed compared to AngleSharp. AngleSharp has been measured in an early stage (v0.8.6), i.e. it is likely that the performance of AngleSharp will increase even further. While the CsQuery project is ambitious and contains some interesting ideas and features, AngleSharp tries to solve the problem from the other side - follow the standards first and add nice features on top afterwards. The past has shown that implementing fancy features or a non-standard, but better, API first, will lead to problems later on.

In general there are areas where AngleSharp is performing better, and other pages where the validator.nu parser is faster. In most cases the winner does not really matter (cases such as 2ms vs 3ms).

Comparison with Other Solutions

One could also make comparisons to other projects. In the official Performance project (contained in the Visual Studio solution) you will find the Majestic (Majestic 13) parser. This one is nearly always faster than any other solution. Is it the right choice for your project? Probably not. The reason is simple: Majestic does not build a DOM, it also does not care about special tags, meanings and the HTML error correction. Basically Majestic is AngleSharp reduced to its tokenizer, with the tokenizer being a bit simpler.

This is also the reason for excluding Majestic from the performance comparison. However, you are (for your own pleasure) of course allowed to include Majestic again. The code is already checked-in.

Current Performance

Performance is valued high - even though standard-compliance is valued higher. AngleSharp's repository comes with a set of benchmarks.

HTML Parser

The setup for this test was:

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

The results are displayed below.

DOM Querying / CSS Selectors

The setup for this test was:

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

The results are displayed below.