John Snow <js...@redhat.com> writes: > On 05/06/2015 11:19 AM, Markus Armbruster wrote: >> 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 :) >> > > When you're right, you're right. The difference may not be statistically > meaningful, but with today's current planetary alignment, using > sprintf() to batch the sends instead of my home-rolled nib computation > function, I can eke out a few more tenths of a second.
:) > If there are no objections, I will stage patches 1-3 and 5, and resubmit > a quick v2 of just this single patch, unless you want to go ahead and > say that making the edit will be fine, then I will just edit it before > sending the pullreq. Recommend to post the revised patch, with an updated commit message.