From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqF3W-0003Ex-9n for qemu-devel@nongnu.org; Thu, 07 May 2015 02:13:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YqF3S-0001Jv-Sl for qemu-devel@nongnu.org; Thu, 07 May 2015 02:13:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44556) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqF3S-0001Jn-9F for qemu-devel@nongnu.org; Thu, 07 May 2015 02:13:06 -0400 From: Markus Armbruster References: <1430864578-22072-1-git-send-email-jsnow@redhat.com> <1430864578-22072-5-git-send-email-jsnow@redhat.com> <87pp6eusrz.fsf@blackfin.pond.sub.org> <554A2142.7090006@redhat.com> <87y4l13f8z.fsf@blackfin.pond.sub.org> <554A3EE1.6050207@redhat.com> Date: Thu, 07 May 2015 08:13:03 +0200 In-Reply-To: <554A3EE1.6050207@redhat.com> (John Snow's message of "Wed, 06 May 2015 12:18:41 -0400") Message-ID: <87vbg4c3v4.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v3 4/5] qtest: precompute hex nibs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, afaerber@suse.de John Snow writes: > On 05/06/2015 11:19 AM, Markus Armbruster wrote: >> John Snow writes: >> >>> On 05/06/2015 02:25 AM, Markus Armbruster wrote: >>>> John Snow 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.