html5ever is much slower than MyHTML

[DemiMarie]

https://lexborisov.github.io/benchmark-html-persers/ shows html5ever performing very badly against MyHTML, which furthermore has fewer bugs and supports document.write() html5ever supports document.write() in modern versions (thanks @jdm).

[jdm]

html5ever also supports document.write().

[DemiMarie]

@jdm That must be an old version I was thinking of, sorry.

[SimonSapin]

Sorry, I don’t see the point of this issue. “Fewer bugs” is very non-specific. If you’re aware of bugs in the latest version that aren’t listed in https://github.com/servo/html5ever/issues, it’d be more helpful to file them individually.

As to performance, just stating “very bad” isn’t particularly actionable either. Are you interested in investigating low-hanging fruit to fix performance issues?

[nox]

That benchmark doesn't show how html5ever was compiled though.

[SimonSapin]

Closing for lack of actionable items.

[jdm]

The actionable item is attempting to reproduce the results. The benchmark repository looks like it's in good shape for doing that.

[Ygg01]

@jdm Perhaps issue #45 #51 might be more appropriate? I did ask about setting up benchmarks in a way that would work best for all parsers, but got no response, so I thought there wasn't any interest.

AFAICT the https://github.com/lexborisov/benchmark-html-persers uses C bindings for html5ever. I thought those were abandoned more than a year ago.

My thoughts were about maybe using https://github.com/seriyps/html-parsers-benchmark for comparison between different parsers and Criterion.rs for Rust specific.

[jdm]

https://github.com/swizard0/html2html_lib/blob/master/src/lib.rs is the Rust code that parses the document; the benchmark calls that function from C.

[SimonSapin]

The C bindings in this repository were removed a year ago. IIRC they had been broken since we started using string-cache (since string-cache itself doesn’t have a C API), which happened 3 years ago. Also these bindings were only for tokenization.

According to its README.md, this benchmark uses swizard0/html2html_lib which:

• Decodes a UTF-8 byte string
• Parses into an RcDom tree
• Optionally serializes to stdout (this is disabled in the benchmark)
• Drops the tree

The tree cannot be accessed from C. (Which might be good enough for a parser.)

@nox pointed out that MyHTML does YOLO ownership of tree nodes. Whereas our reference counting probably has some overhead. If we take the time to reproduce this benchmark, we should try using a tree with arena-allocated nodes. (And when publishing results, include a date and version numbers…)

[ordian]

I was able to build the benchmarks. See fork.
Here are my local results with top(ish) 11 sites (you can see the plots by clicking on "explore" in the right bottom corner).

[DemiMarie]

MyHTML’s tree design only makes sense with a GC or with an immutable DOM.
So I think that we should try with html5ever having an arena. Gumbo has a pluggable allocator, so we should give it an arena too.

Could it be that the DOM-manipulation methods in RcDom are not getting inlined? That would explain the slowdown.

Another thought: tree structures like the DOM are not one of Rust’s strengths, and RcDom has what appears to be a lot of overhead in order to be able to be written completely in safe code. I wonder if an unsafe, immutable DOM (that used raw pointers, like one would write in C) would be faster.

[SimonSapin]

The benchmark’s extern fn parse_document uses TendrilSink::read_from with a &[u8] slice, treating it as a stream of unknown length that is copied into 4 KB chunks. It should use one instead, to use the slice as a single chunk. (Even that does a extra copy, though I don’t know if that’s significant compared to parsing time.)

[SimonSapin]

I’ve added an arena-allocated tree, as an alternative to rcdom: #288. It doesn’t use unsafe (except in the arena library), and shouldn’t have more overhead than a tree based on raw pointers.