<div dir="ltr">On Thu, Dec 5, 2013 at 6:15 AM, mat henshall <span dir="ltr"><<a href="mailto:mat@squareconnect.com" target="_blank">mat@squareconnect.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>I do agree on the need for using optimized parsers (we have an xml parser that fits in a few hundred bytes of code and read only memory) that is extremely fast and efficient on small devices. BTW the trick to avoid the tag comparison is to convert the various tags and namespaces to hash values as they come in during parsing and then only compare on the hash value. We have a small utility that calculates the hash values and writes as a header file as part of the compile time all the possible namespaces and tag names that we are interested in. Extremely efficient in terms of both computation and memory space. Careful choice of the hash algorithm means very little chance of collision.</div>

<div><br></div></div></div></blockquote><div><br></div><div>That's a neat idea - I was intending to add in attribute hashing in order to handle the well-formedness constraints (and also optimize attribute searches in general), but I'd not thought about compile-time precalculation of hashes, that's terribly clever, and an idea I'll shamelessly steal. FWIW, I was also going to build a simplistic single-hash Bloom on parse to elide some searches, too.</div>
<div><br></div><div>Are you using any particular hash algorithm, or are you generating a perfect hash at buildtime too?</div><div><br></div><div>Dave.</div></div></div></div>