does, however, like M4 still have the strange behaviour to be slower on PreparedStatements. When swithing from server side prepared statements, to Java emulated prepared statements, the performance goes to the same level as simple batched statements, while Java wise, the emulated version is much more computational extensive. I'm under the impression that for update queries we have around the absolute minimum of data sent over at this moment, hence the 'gap' we have with MySQL must be in the engine and/or the driver. For the latter I will have to investigate where shortcuts can be made, or inefficient structures are being used (such as very frequent Map lookups with few entries). This benchmark only tests update queries (inserts, updates, deletes), hence there is a need to revive a select based benchmark, or create one to get an idea how we perform in other use cases. A conclusion from the latest improvements is that searching for newlines appears to be expensive in both Java as well as C. (Smack tests showed a 10x speedup). Future improvements on these responses from the server that are a tabular result can be: - change header format for easier parsing (I don't expect much from this) - replace newlines by integer lengths to avoid string scanning - make parsing of tabular results easier/less expensive by avoiding string escaping