From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqSOL-0003FL-1Y for qemu-devel@nongnu.org; Thu, 07 May 2015 16:27:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YqSOH-00082i-SN for qemu-devel@nongnu.org; Thu, 07 May 2015 16:27:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqSOH-00082e-KL for qemu-devel@nongnu.org; Thu, 07 May 2015 16:27:29 -0400 Message-ID: <554BCAB0.9030707@redhat.com> Date: Thu, 07 May 2015 14:27:28 -0600 From: Eric Blake 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> <554A3EE1.6050207@redhat.com> In-Reply-To: <554A3EE1.6050207@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BWOpP3l0b6a6h9r190kp2tVCvIKu2sM5S" 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 , Markus Armbruster Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, afaerber@suse.de This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BWOpP3l0b6a6h9r190kp2tVCvIKu2sM5S Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/06/2015 10:18 AM, John Snow wrote: >> To find out, add just buffering. Something like this in your patch >> instead of byte2hex(): >> >> for (i =3D 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 :) >> >=20 > When you're right, you're right. The difference may not be statisticall= y > 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. I'm a bit surprised - making a function call per byte generally executes more instructions than open-coding the conversion (albeit the branch prediction in the hardware probably does fairly well over long strings, since it is a tight and predictable loop). Remember, sprintf() has to decode the format string on every call (unless the compiler is smart enough to open-code what sprintf would do). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --BWOpP3l0b6a6h9r190kp2tVCvIKu2sM5S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVS8qwAAoJEKeha0olJ0NqoDAIAJECuEBvuF+u3w6rvDqmXpt1 DZiVLWE78qYAG9BSpi0yIbeW4m5re1PClyqG6N/gTqJnGMMfEOA6ESwKM4hg9YMi Gw6dm6w4W9IeKlOgLSJ1k4HlBxprrM+g5cVy/08H8gNiEVwwifjoCPMYO54pyb2e xaUwWNG1IhEmIxXeHaRJ3mdfopzb1j5ILyZJKne51vU4yB5euvf7mlY4EhQRbwuv oShchgKad/j/xPiIdrkCqViuTh3rv9HBvfuw+qCqsVGP/EUvQcBpQhYXdrhWUsjZ WZCcvdRt9DcHNdG6dcV/dxvSRpdnm5nZ4s4urEPZyjwgSs+9pimCmvCqUcQlUtY= =NCQ0 -----END PGP SIGNATURE----- --BWOpP3l0b6a6h9r190kp2tVCvIKu2sM5S--