I imagine that there is such a threshold, but that the particular block size would vary from device to device, depending on processor, cache characteristics and processor speed.
-- Keith -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ted Peters Sent: Friday, July 16, 2004 11:25 AM To: Palm Developer Forum Subject: Re: MemCopy This brings up another question that I have on MemMove: in a 68k app running on ARM hardware, is there a size threshold where calling MemMove winds up being faster than writing your own byte copying code? I'm assuming that there is an ARM-native implementation of MemMove, and if you copy enough bytes this faster implementation will overcome the overhead. Thanks, Ted Peters On Jul 16, 2004, at 11:15 AM, Keith Rollin wrote: > Personally, I'd just use: > > audio_setup_destination = audio_setup_source; > > The above takes up about the same amount of object code as calling > MemMove (14 for MemMove vs. 20 bytes in this particular case), is > faster since you avoid the overhead of a system function call, and is > more portable since it doesn't use any OS-specific API. > > Keep in mind, however, that neither the above nor the use of MemMove > perform a *deep* copy. That is, hLangVersion and the other MemHandles > in the block will still refer to the same data as the original buffer. > Care must be taken either to (a) dispose of those blocks only once > regardless of how many audio_setup structure point to them, or (b) > clone those as well using MemHandleNew and MemMove. > > -- Keith -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
