Why pointers are faster and more efficient

Question

I read this in a C book :

Pointers have several uses, including: • Creating fast and efficient code • Providing a convenient means for addressing many types of problems • Supporting dynamic memory allocation • Making expressions compact and succinct • Providing the ability to pass data structures by pointer without incurring a large overhead • Protecting data passed as a parameter to a function. Faster and more efficient code can be written because pointers are closer to the hardware. That is, the compiler can more easily translate the operation into machine code. There is not as much overhead associated with pointers as might be present with other operators.

Q. How is 'compiler translating operations into machine code easily' related to faster working of code ? It could be easier for the compiler to convert, but how does it affect the speed of created executable ?

Q. Since, everything gets converted into the machine instructions at the end, how is using pointers gonna give some special speedup if I rather pass say normal variables ?

Could someone give some insight on how using pointers could make program faster ?

P.S. I understand that instead of passing a massive 'object', passing a pointer would be better in terms of resources being copied, is there anything more to it because of which pointers are preferred ?

Solution 1

That quote claims that code using pointers is faster, but it doesn't say faster than what.

The most common claim is that code using pointers is faster than equivalent code using array indices. For example:

char s[] = "hello, world";
char *p = s;
while (*p != '\0') {
    /* do something with *p */
    p ++;
}

vs.

char s[] = "hello, world";
int i = 0;
while (s[i] != '\0') {
    /* do something with s[i] */
    i ++;
}

Very old c compilers might have generated significantly faster code for the first version than for the second. For modern optimizing compilers, it's unlikely to make any difference. A good compiler might even generate exactly the same machine code for both (I haven't tested this).

It's more important to write clear C code and let the compiler generate the best machine code to implement it.

Solution 2

That is absolutely true -- pointers and references are closer to the machine language. The point that your text is making is more about copying data in a "deep" copy vs. assigning a memory location in a "shallow" copy. I know full well that this is absolutely true. As an example, Visual Basic can be somewhat ambiguous in comparison to C++ in this regard (perhaps off topic, but still relevant) and I was able to make a multiplication routine run on the order of a hundred times faster with larger memory spaces owed to the fact that I was able to avoid most of the allocations and data juggling that was going in VB, by implementing the algorithm with pointers and references in C++.

If you have an array and a routine that needs to read from the array, it's much much faster to copy only the memory location of the data structure rather than the entire contents of the target data structure and that goes for any programming language. The only rule you need to follow is that if you write to the memory passed by reference or pointer it will alter the original data structure.

Comments

[Iwillnotexist Idonotexist]

I disagree somewhat. When a char[] is used this way, it decays to a char* anyways. But you're off in the right direction – The first thing that came to mind for me was the difference between indexing though a char* versus a C++ std::vector<char>. The former is often a single instruction that the compiler groks perfectly and can vectorize, the latter is usually a function call. Code that uses this sort of access in a vector is almost never vectorized, unless you've got a compiler which has special knowledge of vector.

[Keith Thompson]

The question is tagged C, so std::vector is irrelevant.

[Iwillnotexist Idonotexist]

Your first statement applies here: faster than what? C arrays decay to pointers in this context (in most contexts), and there isn't any other tool that C provides that achieves the same thing as pointers. Moreover the summary of the book that OP linked to ends with "This comprehensive book has the information you need, whether you’re a beginner or an experienced C or C++ programmer or developer.". Knowing that the book's audience includes C++ programmers can shed light on why that statement was made.

[JustKevin]

They don't generate the same machine code. The first snip increments the memory location itself, so there would be a cmp [location], value instruction. The second snip increments the memory offset, so there would be at least two instructions -- one to add the base location of the array and the offset being incremented and another to compare the value stored in the memory location to the null value given.

[Jens Gustedt]

"absolutely true" ? No, not really. Modern architectures happily do relative addressing with a base register and an offset. No need for pointers at all to be efficient.

[Jens Gustedt]

@JustKevin, not the same assembler, probably true, but most likely not more statements. Modern architectures happily to relative addressing.

[JustKevin]

How does the compiler know where the variables are? If you have an 'int Value;' the compiler sees it as a memory location. If you have a 'void *Pointer;' the compiler sees it as a memory location as well, but a memory location holding a memory location. When you use large data structures it is an absolute that you do not want to be juggling your data around on the stack and doing all kinds of deep copy routines, so I stick by both my statement and my comment above.

[JustKevin]

And if they don't generate the same op codes, snip 1 consumes at least as many cycles as snip 2. The burden would then be on you to show they consume the same number of cycles.

[Deduplicator]

Anyway, never forget the "as-if-rule", and what startling optimizations modern compilers can perform.

[Deduplicator]

@JustKevin Both are liable to generate exactly the same compiled code. I'm sure most compiler developers (especially the big teams) would treat sub-optimal code for #1 as a severe problem needing a timely fix.

[Keith Thompson]

@JustKevin: Whether they generate the same machine code depends on the compiler. They certainly can result in exactly the same machine code because they have the same visible behavior.

[JustKevin]

Best practice is not to assume specific optimizations will occur.

[Keith Thompson]

Do you have concrete evidence that pointers are faster (than what) in C? Note that the question isn't about C++ or Visual Basic.

[JustKevin]

Faster than copying the entire dataset into a function that only needs to read the dataset, for one. 'struct' was, in fact, originally part of the C language.

[Spektre]

@KeithThompson more obvious speedup is passing struct and pointer to struct as function operands then indexing an array ... (which significantly impact heap trashing and memory size needed to transfer). also function pointers are nice to avoid if's or switch statements

[Keith Thompson]

Certainly there are cases where code using pointers is faster than code not using pointers. The claim is that pointers are generally faster (than what??), and you seem to be saying that this is always the case. It isn't. See my answer.

[JustKevin]

I provided a counter example. I challenge you to do the same.