Update maybe_xml in compare project to the latest version and add quick-xml borrowed to compare table

[Mingun]

I found, that at least part of our slowdown against maybe_xml is because we benchmarked in buffered mode, while maybe_xml completely allocation-free. Add the same variant for quick-xml

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (222532c) 65.06% compared to head (82cc0da) 65.06%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #691   +/-   ##
=======================================
  Coverage   65.06%   65.06%           
=======================================
  Files          38       38           
  Lines       17942    17942           
=======================================
  Hits        11674    11674           
  Misses       6268     6268           

Flag	Coverage Δ
unittests	65.06% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dralley]

I found, that at least part of our slowdown against maybe_xml is because we benchmarked in buffered mode, while maybe_xml completely allocation-free. Add the same variant for quick-xml

How much was it reduced, and have you done any profiling?

[Mingun]

Not much actually. After the change we win in couple tests, but in other we still 1.5x-2x slower that maybe_xml. I did not ran the profiler yet (I need to find the right tool and how to correctly interpret the results, my experience in profiling is almost zero).

I think about two possible reasons:

• maybe_xml parser consist from const functions so maybe it is greatly optimized by the compiler;
• maybe_xml performs lazy detection of end of the tag name in start/empty tags (<tag attributes...>). Actually, in the benchmark it never runs the corresponding piece of code. Because tags are significant part of any XML, I think, this could be major cause of slow down.

[dralley]

I forget that you use Windows, it's definitely more challenging on Windows than Linux.

If there are any samples you'd like to see profiled I can run them for you. I have a few real-world cases in mind that I could test out.

[Mingun]

Right now I'm not know from where I should start. I tried to benchmark the new parser and unfortunately it is always 2x slower that current implementation. I expected an improvement or at least the same results. Need to figure out why it so slow, because the new implementation is definitely simpler to understand. It will be great to benchmark and profile the quick_xml::parser::Parser separately to see where the bottleneck. I will try to do that.

[Mingun]

Well, just checked -- quick_xml::parser::Parser as fast as maybe_xml (only 1-2 µs slower than it, but I never tried to made optimizations) i. e. about 1.5x-2x faster than current quick_xml implementation. So at least I'm on the right path.