> Unfortunately I still do not have an isolated benchmark... But I've read > your README and you suggested to use pure Lua implementation for new > projects. So we tried to go that route, but we got numerous trace aborts > due to some NYI (I do not remember which exactly, but there were two of > them with v2.0). > > Then we tried your implementation, and got everything JIT compiled, and it > was faster. May be with v2.1 that situation will change. OK, that is interesting. I know some things are actually slower the way I implemented them (for instance float numbers serialization). > Our use case is a bit specialized, we have a known structure (defined in > another messagepack objects elsewhere) and use only arrays. So in order > to avoid ipairs we've supplied table classifier that says that any table > is an array, not a hash. This is a good idea, the default classifier should be avoided anyway because it is slow. It is also slightly broken actually, I will replace the implementation by another one soon.