-1

I don't care about the NULL terminator so I have two choices:

strcpy(createTabStmt, "CREATE TABLE "); //shorter and more readable code

Or

memcpy(createTabStmt, "CREATE TABLE ", sizeof ("CREATE TABLE ") - 1); //faster?

Is the memcpy version always faster?

--

If that's true, then I think a macro can make the readability as good as strcpy:

#define MEMCPY_LITERAL(ptr,literal) memcpy(ptr, literal, sizeof (literal) - 1)

--

I thought the memcpy version has one more constant sizeof ("CREATE TABLE ") - 1. So it uses more space. Is that true?

cshu
  • 5,654
  • 28
  • 44
  • 4
    Is this the bottleneck in your program? If not, you are worrying about a negligible performance difference for no real gain. Premature optimization is a bad thing. Premature micro-optimization is horrible. – cdhowie Jul 28 '14 at 07:16
  • What does `sizeof ("CREATE TABLE ")` evaluate to? – David Heffernan Jul 28 '14 at 07:19
  • They're not equivalent. The `strcpy` form writes one extra byte. I'm not sure if you care, but if not, why are you going to the trouble to subtract one in the second version? – R.. GitHub STOP HELPING ICE Jul 28 '14 at 07:20
  • http://stackoverflow.com/questions/7776085/why-is-memcpy-and-memmove-faster-than-pointer-increments – David Ranieri Jul 28 '14 at 07:20
  • 1
    @DavidHeffernan: The size of the object: 14. – R.. GitHub STOP HELPING ICE Jul 28 '14 at 07:21
  • I doubt there's any noticeable performance difference between the two. On the general case `memcpy` may be a better (secure) alternative though since it does not rely on the string terminator character. – dragosht Jul 28 '14 at 07:22
  • @R I assumed that literal is char* and this would be size of pointer. – David Heffernan Jul 28 '14 at 07:25
  • The answer of witch is faster depends on the implementation. Use the function for which it's intended to, `strcpy` for string and `memcpy` for raw buffers. –  Jul 28 '14 at 07:25
  • @DavidHeffernan `sizeof` is correctly used (yields the size of the object, 14) – David Ranieri Jul 28 '14 at 07:31
  • @cdhowie Let's say I'm not doing software engineering or any optimization. It's only a question about characteristics of C programming language. – cshu Jul 28 '14 at 07:45
  • `sizeof ("CREATE TABLE ") - 1);` : You should not make `-1` in this case. (this meaning would be different to `strcpy` version.) – BLUEPIXY Jul 28 '14 at 08:26
  • @BLUEPIXY I mentioned "I don't care about the NULL terminator", `-1` doesn't matters to me in this case. – cshu Jul 28 '14 at 08:31
  • It can be said to be faster than always just for NUL. – BLUEPIXY Jul 28 '14 at 09:25
  • @Griddoor But this isn't a question about the C programming language really, it's more of a question about the speed of specific functions in the particular implementation you are using. – cdhowie Jul 28 '14 at 13:51

4 Answers4

4

Assuming the source is a literal, I would expect any decent optimizing compiler to do the same for either one (modulo the fact that your memcpy version is writing one byte fewer): either call memcpy with an appropriate size, or generate inline code to store the the contents to the destination directly. You can verify this with gcc and compatible compilers by using -S instead of -c to output assembly language, or by disassembling the output program.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
0

Strcpy will be heavily optimized, my expectation is that you will be unable to measure a difference between these two statements. That, and the database is going to do thousands and thousands of things on a CREATE TABLE, so you should be optimizing for readability here. Just use strcpy, people know what it is, the compiler knows what it is, it works perfectly for what you want.

U2EF1
  • 12,907
  • 3
  • 35
  • 37
0

If size is known, normally a non-naive implementation of memcpy is faster than strcpy, since it takes profit of the CPU's data bus size. For example, if you are to copy 16 bytes, a good implementation in a 64 bit CPU will break down the data transfer in two 8 byte copies. This is achieved by casting the source and destination pointers as 64 bit variable pointers, and then reading/writing memory with two iterations.

Check this link: Understanding the source code of memcpy()

Community
  • 1
  • 1
Claudi
  • 5,224
  • 17
  • 30
0

as a ground rule you should use strcpy for strings and memcpy for data. Once you start changing it for negligible performance saving, you make the code unreadable and confusing.

This also goes for macros - you should also avoid them as well, as they can cause compile errors for anyone that rewrites your code(or for you several months/years from now)

This goes in most cases, unless you write code where the performance is crucial(most cases it isn't)

Shlomi Agiv
  • 1,183
  • 7
  • 17
  • Disagree with "as a ground rule you should use strcpy for strings and memcpy for data.". String manipulation is very commonly a source of overall performance issues so "changing it for negligible performance saving" is a false premise. OP's example may be over-simplistic as so to support your idea concerning negligible performance saving, yet the title question is still a real valid concern and not answered here. – chux - Reinstate Monica Apr 06 '18 at 16:29