qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 4/5] qtest: precompute hex nibs


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v3 4/5] qtest: precompute hex nibs
Date: Wed, 06 May 2015 17:19:40 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

John Snow <address@hidden> writes:

> On 05/06/2015 02:25 AM, Markus Armbruster wrote:
>> John Snow <address@hidden> 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 :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]