<div dir="ltr">Oh, you're correct! It's unable to parse that file! The files is a test suite file from the XML spec, I guess hexml is unable to parse this one. I'll remove it from my benchmark suite in favor of something that does parse. <div><br></div><div>Cheers!</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 December 2016 at 14:55, Harendra Kumar <span dir="ltr"><<a href="mailto:harendra.kumar@gmail.com" target="_blank">harendra.kumar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 23 December 2016 at 03:23, Christopher Done <span dir="ltr"><<a href="mailto:chrisdone@gmail.com" target="_blank">chrisdone@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">But if you scroll down the README to the 182kb file example, you see that hexml takes 33us and xeno takes 111us. That's surprising to me because I'm doing just a walk across a string and hexml is doing a full parse. It's written in C, but still, 3x faster AND doing allocations and more work.</p></blockquote><div><br></div></span><div>hexml being a full parser might fail, on the other hand your program unconditionally walks the bytestring. Are you sure hexml is actually completing and not aborting or short-circuiting because of a parse error or some other error? In all other data points xeno is taking much less time than hexml except this one. So I am suspecting it could be a problem with the input, making hexml fail silently. I see that the file used on this data point has japanese characters, maybe hexml is not able to handle those?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-harendra</div></font></span></div></div></div>
</blockquote></div><br></div>