fast-float-rust VS roxmltree

I'd like the mention my own refactoring of fast-float-rust to remove nearly all unsafe code for merging into Rust core library which left the performance identical to the previous implementation.

JSON is an interesting example, since the syntax of valid floats is slightly different than what Rust expects. Luckily, I'm the author of a minimal, and am also the author of a PR to bring this to fast-float-rust.

[4] https://github.com/aldanor/fast-float-rust/

It seems also dependent on the processor: https://github.com/aldanor/fast-float-rust/#intel-i7-4771

I've already done that (just pushed it - here).

This is exactly what I needed when implementing xml-mut :D I have used roxmltree instead and manipulated text directly. will try to rewrite it using Xot.

In regards to the benchmarks, It makes sense to measure serializing/deserializing for parser crates. but since we are talking about dom implementations, metrics like traversal/iteration speed or insert/modification performance would be useful. a good example is roxmltree crate (readonly xml dom) which benches traversal/iteration performance and shows that by only focusing on readonly usecases, it gains substantial performance gains.

For xml parsing, I find https://github.com/RazrFalcon/roxmltree as a really good crate. It’s fast, light, and well documented/maintained. I have so much respect for the maintainer’s approach to merging PRs and the way they consider what’s important for the crate

I understand. But I've also wrote enough parsers and performance sensitive code in Rust (ttf-parser, tiny-skia, roxmltree). And in my experience, unsafe is not needed in 99% of the cases. Even something as performance sensitive as tiny-skia is unsafe-free (with some nuances).