
On Thu, 2004-12-16 at 20:04, RJ wrote:
Doh. Thanks Todd,
At 04:55 PM 12/16/2004 -0500, Todd Miller wrote:
try: repr(src._data) ... Other buffers, e.g. a string, might not.
Which is fine for this app, so I will.
It looks to me like you forgot to import Numeric
Yep. I screwed up the import statements - I'll re-do it tomorrow. In that light, it is interesting that the assign N were always longer than the n ones...
To be safe, check the .is_c_array() method.
Will do. I am also a little concerned about the address changing in a long-running process (literally, weeks), so I might check that too.
As long as you let the NumArray allocate its own memory, it will allocate a numarray.memory object and those don't move. If you resize the array, that's a different story...
Also, why is assignment from a (ctypes.c_long * 2000)() to a numarray so much slower than a memmove()? Does the assign make a temp buffer?
For the assignment to numarray, I think the ctype is opaque and as a result Python uses the sequence protocol; this is a huge amount of work compared to a tight C loop moving bytes. I think every 4 bytes the ctype is doing a method call and building a Python long, numarray is doing a method call and extracting a Python long, then the Python long is destructed. I may be missing something, but the comparisons of for loop, map, and slice look like they're only doing 1000 moves but the array assigments are doing 10000, so I think there's another factor of 10 missing in that comparison.