[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: |
Thu, 07 May 2015 08:13:03 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
John Snow <address@hidden> writes:
> On 05/06/2015 11:19 AM, Markus Armbruster wrote:
>> 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 :)
>>
>
> 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.
- [Qemu-devel] [PATCH v3 0/5] qtest: base64 r/w and faster memset, John Snow, 2015/05/05
- [Qemu-devel] [PATCH v3 4/5] qtest: precompute hex nibs, John Snow, 2015/05/05
- Re: [Qemu-devel] [PATCH v3 4/5] qtest: precompute hex nibs, Markus Armbruster, 2015/05/06
- Re: [Qemu-devel] [PATCH v3 4/5] qtest: precompute hex nibs, Eric Blake, 2015/05/07
- Re: [Qemu-devel] [PATCH v3 4/5] qtest: precompute hex nibs, Markus Armbruster, 2015/05/08
- Re: [Qemu-devel] [PATCH v3 4/5] qtest: precompute hex nibs, John Snow, 2015/05/08
- Re: [Qemu-devel] [PATCH v3 4/5] qtest: precompute hex nibs, Eric Blake, 2015/05/08
[Qemu-devel] [PATCH v3 1/5] qtest: allow arbitrarily long sends, John Snow, 2015/05/05
[Qemu-devel] [PATCH v3 3/5] qtest: add memset to qtest protocol, John Snow, 2015/05/05
[Qemu-devel] [PATCH v3 2/5] qtest: Add base64 encoded read/write, John Snow, 2015/05/05