Thank you very much John,
I missed the point to add the *and* to workaround the long result issue!
I think I understand it now.
I am timing the code once translated, so here are the results for the
crc calculation function. I did expected a big gap, as this does a lot
of lookups to the crc table (a typical call gets 20-250 characters long)
so the C extension version with a simple array and pointers perform
really a lot better. The C code was glued with pyrex.
Fortunately I don't need a great performance for this code in the PocketPC!
C CalcCRC16
1 loops -> 4.75e-006 secs
210562 loops -> 0.133 secs
1580403 loops -> 0.973 secs
1580403 loops -> 0.973 secs 0.971 secs 1.12 secs
1580403 loops, best of 3 trials: 0.614 usec per loop
Python CalcCRC16
1 loops -> 0.000102 secs
9834 loops -> 0.832 secs
11824 loops -> 1.01 secs
11824 loops -> 1.01 secs 1.02 secs 1.01 secs
11824 loops, best of 3 trials: 85.1 usec per loop
Tested with: CalcCRC16('[EMAIL PROTECTED]')
C Version:
long CalcCRC16(char *str)
{
long crc;
for(crc = 0xFFFF; *str != 0; str++) {
crc = CRC16Table [(( crc >> 8 ) & 255 )] ^ ( crc << 8 ) ^ *str;
}
return crc;
}
John Machin escribió:
>For a start,
>
>
>>>>22002496167782427386022437441624938050682666541682 & 0xffffffffL
>>>>
>>>>
>67560050L
>
>
>so you could just do that at the end.
>But you don't really want to be carrying all that rubbish around,
>getting longer and longer each time around the loop. And let's further
>the translation into Python by getting rid of the xrange gizmoid and a
>few other undesirables:
>
># tested on your 1 test value
>def CalcCRC16v2(astr): # don't shadow str()
> # global gCRC16Table # don't need this
> crc = 0xFFFFL # start as a long
> for c in astr:
> crc = gCRC16Table[((crc >> 8) & 255)] ^ ((crc & 0xFFFFFF) << 8)
>^ ord(c)
> return crc
>
>That should get you going. Although the whole calculation will be done
>with longs instead of ints, the longs will never exceed 32 bits so it
>shouldn't be too slow.
>
>HTH,
>John
>
>
>
--
http://mail.python.org/mailman/listinfo/python-list
