On 2014/12/10 11:18, Amit Shah wrote:
> On (Mon) 24 Nov 2014 [19:55:50], arei.gong...@huawei.com wrote:
>> From: ChenLiang <chenlian...@huawei.com>
>>
>> The logic of old code is correct. But Checking byte by byte will
>> consume time after an concurrency scene.
>>
>> Signed-off-by: ChenLiang <chenlian...@huawei.com>
>> Signed-off-by: Gonglei <arei.gong...@huawei.com>
>> ---
>> xbzrle.c | 28 ++++++++++++++++++----------
>> 1 file changed, 18 insertions(+), 10 deletions(-)
>>
>> diff --git a/xbzrle.c b/xbzrle.c
>> index d27a140..0477367 100644
>> --- a/xbzrle.c
>> +++ b/xbzrle.c
>> @@ -50,16 +50,24 @@ int xbzrle_encode_buffer(uint8_t *old_buf, uint8_t
>> *new_buf, int slen,
>>
>> /* word at a time for speed */
>> if (!res) {
>> - while (i < slen &&
>> - (*(long *)(old_buf + i)) == (*(long *)(new_buf + i))) {
>> - i += sizeof(long);
>> - zrun_len += sizeof(long);
>> - }
>> -
>> - /* go over the rest */
>> - while (i < slen && old_buf[i] == new_buf[i]) {
>> - zrun_len++;
>> - i++;
>> + while (i < slen) {
>> + if ((*(long *)(old_buf + i)) == (*(long *)(new_buf + i))) {
>> + i += sizeof(long);
>> + zrun_len += sizeof(long);
>> + } else {
>> + /* go over the rest */
>> + for (j = 0; j < sizeof(long); j++) {
>> + if (old_buf[i] == new_buf[i]) {
>> + i++;
>> + zrun_len++;
>
> I don't see how this is different from the code it's replacing. The
> check and increments are all the same. Difficult to see why there'll
> be a speed benefit. Can you please explain? Do you have any
> performance numbers for before/after?
>
> Thanks,
>
> Amit
>
> .
>
Hi Amit:
+ for (j = 0; j < sizeof(long); j++) {
+ if (old_buf[i] == new_buf[i]) {
+ i++;
+ zrun_len++;
+ } else {
+ break;
+ }
+ }
+ if (j != sizeof(long)) {
+ break;
+ }
The branch of *j != sizeof(long)* may not be hit after an concurrency scene.
so we can continue doing "(*(long *)(old_buf + i)) == (*(long *)(new_buf + i))".
On the another side the old code does "old_buf[i] == new_buf[i]".
To be honest, This scene is rare.
Best regards
ChenLiang
