&gt; Do you think the use of parser generators is practical also for performance-critical binary data?<p>That&#x27;s not a question I consider very important, because prioritizing performance over correctness (safety) is irresponsible.<p>That said, using a parser generator shouldn&#x27;t have a significant impact on performance.  When a network is involved, the parser isn&#x27;t going to be the bottleneck anyway.<p>&gt; video<p>I am not very familiar with the details of video formats, but I would suggest trying the parser combinator library Meredith mentions in the talk in my previous [1], known as &quot;hammer&quot;[2]. It&#x27;s very easy to use, and it has specific support for bit-level parsing of binary formats.<p>&gt; numPersons 2<p>I highly recommend <i>not</i> using formats like this, because it&#x27;s more complex than deterministic context-free. Using a length field requires that the parser remember state. It&#x27;s also redundant information, creating the possibility of a miss-match between the number specified in &quot;numPersons&quot; and the actual number of rows.<p>A format that uses s-expressions would be safer and more easier to implement:<p><pre><code>    (ancestry
      (ancestor
        (person john &quot;John Doe&quot;)
        (person jane &quot;Jane Doe&quot;)
      )
    )
</code></pre>
The closing tag of the s-expression provides a similar benefit as the num* fields by simply marking the end of a complete record&#x2F;field.<p>&gt; That&#x27;s so trivial that I would never want to depend on a parser generator<p>Is it <i>really</i> &quot;trivial&quot;? Or is your parse that you write in 10 minutes accepting ambiguous or invalid data? Is it actually checking for <i>all</i> of the error conditions? For most real-world grammars, it&#x27;s unlikely you will catch <i>all</i> of the subtle ambiguities, interactions, and edge cases.<p>The benefit of using a parser generator is that those <i>entire classes</i> of bugs are impossible.<p>&gt; check (relational) integrity<p>In the trivial example you gave, you <i>shouldn&#x27;t have</i> a grammar that requires checking relational integrity. In a more complex grammar, such checks would be the job of whatever is walking the AST that the parser returns. Parsers interpret syntax, not semantics.<p>&gt; If I leave away the num* fields above, the parser would need one token of lookahead.<p>You need at least one token of lookahead anyway. Including the num* fields means the parser needs to remember and manage <i>state</i>.<p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;UpstandingHackers&#x2F;hammer" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;UpstandingHackers&#x2F;hammer</a>