Which is faster?...
February 17, 2000 07:27 PM
memcpy or CopyMemory?
They do the same thing, right? so which is faster?
Help me out! I''m an idiot!
Alexbigshot@austin.rr.comFoolish man give wife grand piano. Wise man give wife upright organ.
122
February 17, 2000 08:00 PM
Hmm, I''ve never heard of CopyMemory. I''ve always used memcpy. I''d use memcpy just because more people (i don''t think CopyMemory is ansi C or is iso, i always get confused). But, maybe memcpy isn''t either. Just pick one and stick to it, that''s the way to go.
February 17, 2000 08:07 PM
I don''t think either are ANSI C. Memcpy is part of the include file memory.h and CopyMemory is part of the Windows SDK (in windows.h). I just don''t know which is better. They''re the same as far as I can tell.
Al
Al
2,380
February 17, 2000 08:11 PM
CopyMemory is a Windows thing, and it''s just a macro for memcpy, so the speed will be the exact same.
122
February 17, 2000 09:08 PM
memcpy is an ANSI function, but the accepted header file is string.h. There is no reason to use functions like CopyMemory, ZeroMemory,... except to make your code unportable. Just use memcpy, memset, ...
February 17, 2000 09:33 PM
Actually CopyMemory is a real implemented function on the IA64 architecture with Windows NT. Though I don''t think many of you are targeting that platform. 
But if you ever do, feel free to use CopyMemory instead of memcpy.
(Ok, ok, technically, CopyMemory is a macro for RtlCopyMemory which is an actual function. But it''s still not memcpy.)
But if you ever do, feel free to use CopyMemory instead of memcpy.(Ok, ok, technically, CopyMemory is a macro for RtlCopyMemory which is an actual function. But it''s still not memcpy.)
2,082
February 17, 2000 09:35 PM
Even if that''s true Si... there''s still no reason why the runtime libraries can''t implement memcpy the same way. In which case you''re still better off using it, since it''s fast AND portable.
-Brian
-Brian
February 17, 2000 10:31 PM
Tongue in cheek, Brian, Tongue in cheek.
Oh, but there are reasons that library functions can sometimes not do things as efficiently as OS calls. On superscalar RISC processors, for example, they often reserve certain registers for use by OS functions alone, as part of the calling convention. The availability of those extra registers can often improve the speed of a function.
Oh, but there are reasons that library functions can sometimes not do things as efficiently as OS calls. On superscalar RISC processors, for example, they often reserve certain registers for use by OS functions alone, as part of the calling convention. The availability of those extra registers can often improve the speed of a function.
2,082
February 17, 2000 11:13 PM
Indeed, my friend. But I still don''t see why any standard call couldn''t just be another name for a faster OS instruction. The library function can certainly wrap mega-low-level OS calls, no? Then again, in my previous post I said there''s "no reason" ... which is more than enough reason for our pals in Seattle. (:
-Brian
-Brian
122
February 18, 2000 07:52 PM
But, there is also the overhead of a context switch involved in making an OS call, which is the difference between a library call and a system call. If CopyMemory is a system call, I doubt it would even keep up with memcpy. Plus, extra ''secret'' registers aren''t going to help in a memory copy anyway. Maybe in other situations, but I seriously doubt in this one. Unless the implementation of memcpy is poorly written, and CopyMemory is optimized, which I wouldn''t put past MS.
Rock
Rock
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
