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/
