#6758 closed enhancement (fixed)
To Improve the efficiency of program execution(shpopen.c & dbfopen.c)
Reported by: | sunxunfeng | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | default | Version: | svn-trunk |
Severity: | normal | Keywords: | |
Cc: |
Description
An integer number multiply by 256 (i * 256) is same as shift left 8 bit (i<<8),shift left is much faster than multiplication.
Attachments (2)
Change History (8)
by , 7 years ago
Attachment: | dbfopen.c.patch added |
---|
comment:1 by , 7 years ago
Did you actually check that this result in a code optimization (looking at assembly code, or benchmarking) ? I guess compilers in optimized mode produce the same code in both cases
comment:3 by , 7 years ago
i = 3; 002C136E mov dword ptr [i],3 i = i*256*256*256; 002C1375 mov eax,dword ptr [i] 002C1378 shl eax,8 002C137B shl eax,8 002C137E shl eax,8 002C1381 mov dword ptr [i],eax i = i<<24; 002C1384 mov eax,dword ptr [i] 002C1387 shl eax,18h 002C138A mov dword ptr [i],eax i = i%256; 002C138D mov eax,dword ptr [i] 002C1390 and eax,800000FFh 002C1395 jns main+4Eh (2C139Eh) 002C1397 dec eax 002C1398 or eax,0FFFFFF00h 002C139D inc eax 002C139E mov dword ptr [i],eax i = i&0xFF; 002C13A1 mov eax,dword ptr [i] 002C13A4 and eax,0FFh 002C13A9 mov dword ptr [i],eax i = i/256/256; 002C13AC mov eax,dword ptr [i] 002C13AF cdq 002C13B0 and edx,0FFh 002C13B6 add eax,edx 002C13B8 sar eax,8 002C13BB cdq 002C13BC and edx,0FFh 002C13C2 add eax,edx 002C13C4 sar eax,8 002C13C7 mov dword ptr [i],eax i = i>>16; 002C13CA mov eax,dword ptr [i] 002C13CD sar eax,10h 002C13D0 mov dword ptr [i],eax return 0; 002C13D3 xor eax,eax
comment:4 by , 7 years ago
int nRecords; unsigned char abyFileHeader[8]; nRecords = 23242341; 00BA13A8 mov dword ptr [ebp-18h],162A665h abyFileHeader[4] = (unsigned char) (nRecords % 256); 00BA13AF mov eax,dword ptr [ebp-18h] 00BA13B2 and eax,800000FFh 00BA13B7 jns main+40h (0BA13C0h) 00BA13B9 dec eax 00BA13BA or eax,0FFFFFF00h 00BA13BF inc eax 00BA13C0 mov byte ptr [ebp-24h],al abyFileHeader[5] = (unsigned char) ((nRecords/256) % 256); 00BA13C3 mov eax,dword ptr [ebp-18h] 00BA13C6 cdq 00BA13C7 and edx,0FFh 00BA13CD add eax,edx 00BA13CF sar eax,8 00BA13D2 and eax,800000FFh 00BA13D7 jns main+60h (0BA13E0h) 00BA13D9 dec eax 00BA13DA or eax,0FFFFFF00h 00BA13DF inc eax 00BA13E0 mov byte ptr [ebp-23h],al abyFileHeader[6] = (unsigned char) ((nRecords/(256*256)) % 256); 00BA13E3 mov eax,dword ptr [ebp-18h] 00BA13E6 cdq 00BA13E7 and edx,0FFFFh 00BA13ED add eax,edx 00BA13EF sar eax,10h 00BA13F2 and eax,800000FFh 00BA13F7 jns main+80h (0BA1400h) 00BA13F9 dec eax 00BA13FA or eax,0FFFFFF00h 00BA13FF inc eax 00BA1400 mov byte ptr [ebp-22h],al abyFileHeader[7] = (unsigned char) ((nRecords/(256*256*256)) % 256); 00BA1403 mov eax,dword ptr [ebp-18h] 00BA1406 cdq 00BA1407 and edx,0FFFFFFh 00BA140D add eax,edx 00BA140F sar eax,18h 00BA1412 and eax,800000FFh 00BA1417 jns main+0A0h (0BA1420h) 00BA1419 dec eax 00BA141A or eax,0FFFFFF00h 00BA141F inc eax 00BA1420 mov byte ptr [ebp-21h],al abyFileHeader[4] = nRecords & 0xFF; 00BA1423 mov eax,dword ptr [ebp-18h] 00BA1426 and eax,0FFh 00BA142B mov byte ptr [ebp-24h],al abyFileHeader[5] = (nRecords>>8) & 0xFF; 00BA142E mov eax,dword ptr [ebp-18h] 00BA1431 sar eax,8 00BA1434 and eax,0FFh 00BA1439 mov byte ptr [ebp-23h],al abyFileHeader[6] = (nRecords>>16) & 0xFF; 00BA143C mov eax,dword ptr [ebp-18h] 00BA143F sar eax,10h 00BA1442 and eax,0FFh 00BA1447 mov byte ptr [ebp-22h],al abyFileHeader[7] = (nRecords>>24) & 0xFF; 00BA144A mov eax,dword ptr [ebp-18h] 00BA144D sar eax,18h 00BA1450 and eax,0FFh 00BA1455 mov byte ptr [ebp-21h],al
comment:6 by , 7 years ago
Oh well, I'm not so convinced that this has a performance effect in practice, but committed your patch since it makes more sense to use shift operators than arithmetic ones in that context.
For a next time, please use a unified diff format for your patch, otherwise that's painful to apply.
Note:
See TracTickets
for help on using tickets.
patch file of dbfopen.c(Rev 36727)