From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57391) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yq221-0002wz-IR for qemu-devel@nongnu.org; Wed, 06 May 2015 12:18:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yq220-0003lc-K8 for qemu-devel@nongnu.org; Wed, 06 May 2015 12:18:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yq220-0003lO-9w for qemu-devel@nongnu.org; Wed, 06 May 2015 12:18:44 -0400 Message-ID: <554A3EE1.6050207@redhat.com> Date: Wed, 06 May 2015 12:18:41 -0400 From: John Snow MIME-Version: 1.0 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> In-Reply-To: <87y4l13f8z.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Markus Armbruster Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, afaerber@suse.de 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. --js