I'll start with the second question since it's easier to answer: some of the other libraries don't support all Avro features (for example I don't think `node-av

I'll start with the second question since it's easier to answer: some of the other libraries don't support all Avro features (for example I don't think `node-avro-io` supports encoding records defined inside arrays), so they're unable to run some of the benchmarks. Both the reference Java implementation and `avsc` are able to parse all these schemas so don't have any -1s in their columns. Performance-wise, the main benefits came from doing as much preprocessing as possible. Here are a couple examples of what is done when a schema is parsed: + All methods for encoding and decoding nested types get fully resolved, removing the need for lookups (for example an array of integers would have a reference to the method for encoding integers). + A constructor, and encoding/decoding methods gets programmatically generated for each record type. This avoids having to iterate over the fields each time. Same for unions. (Having a "Class" for each record type also lets us attach useful methods to its prototype, available for all record instances.) Then there are a few other general ideas like making sure v8 is able to optimize all the methods on the critical path, or reusing buffers as much as possible to avoid allocating too many objects.