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 = 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.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). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
