John Snow <js...@redhat.com> writes: > On 05/06/2015 02:25 AM, Markus Armbruster wrote: >> John Snow <js...@redhat.com> writes: >> >>> Instead of letting printf and friends do this for us >>> one byte at a time, fill a buffer ourselves and then >>> send the entire buffer in one go. >>> >>> This gives a moderate speed improvement over the old >>> method. >> >> Out of curiosity: how much of the improvement is due to doing our own >> buffering instead of printf()'s (assuming the stream is buffered), and >> how much is due to doing our own hex formatting instead of printf()'s? >> > > Out of ignorance: How would I measure?
Heh, well played! The code before the series uses chr unbuffered: for (i = 0; i < len; i++) { qtest_send(chr, "%02x", data[i]); } qtest_send() formats into two bytes, passes them to qemu_chr_fe_write_all(), which writes them to chr. The chr are typically unbuffered, so this could well produce a series of two-byte write() system calls. Adding some buffering will obviously make a difference for larger len. Whether formatting hex digits by hands can make a difference is not obvious. To find out, add just buffering. Something like this in your patch instead of byte2hex(): for (i = 0; i < len; i++) { - qtest_sendf(chr, "%02x", data[i]); + snprintf(&enc[i * 2], 2, "%02x", data[i]); } If the speedup is pretty much entirely due to buffering (which I suspect), then your commit message could use a bit of love :)