Sign in to follow this  
PlasmicSoup

Quick (pun intended) pointer speed question

Recommended Posts

PlasmicSoup    122
Hey there gamedev.net crowd. I've been wondering something for a long time... Is there any speed hit when dereferencing pointers? Is it quicker to dereference a pointer once into a new non-pointer variable, then use that variable, or just use the pointer and dereference it everytime you need to access it? Thanks!

Share this post


Link to post
Share on other sites
jpetrie    13106
Pedantically, of course dereferencing a pointer will incur some "speed hit" (something has to get done and that something will of course take some finite amount of time). Also, extensive pointer-related mucking about may be cache-unfriendly to the point of causing some minor performance issue.

However, there is rarely a need to be concerned about performance on such a microscopic level. It's also not possible to say in general which of the two presented options is "faster" since there isn't a one-to-one mapping between C++ and machine code, and analyzing performance isn't quite that black and white.

Share this post


Link to post
Share on other sites
walkingcarcass    116
When you dereference a pointer into a variable, there is a speed hit because the copy constructor or operator= function gets called. If these are the defaults then they'll just copy member variables around, but that's the kind of optimisation the compiler can figure out for itself. If you have objects of any appreciable size to move around (generally as paramaters) then it's often better to use a pointer.

style-wise, it's a good idea to pass pointers only if you intend the function or method to change the object in question, otherwise pass const references -- this gives you a consistent syntax clue and saves expensive copy operations on complex classes.

Share this post


Link to post
Share on other sites
Quote:
Original post by walkingcarcass
When you dereference a pointer into a variable, there is a speed hit because the copy constructor or operator= function gets called. If these are the defaults then they'll just copy member variables around, but that's the kind of optimisation the compiler can figure out for itself. If you have objects of any appreciable size to move around (generally as paramaters) then it's often better to use a pointer.

style-wise, it's a good idea to pass pointers only if you intend the function or method to change the object in question, otherwise pass const references -- this gives you a consistent syntax clue and saves expensive copy operations on complex classes.


Um, there's a difference between copying something which is pointed at versus referring to something that's pointed at.

int baz;
int *foo = &baz;
int &bar = *foo; // Refers to baz
int bob = *foo; // Copies baz

And, no, style wise it makes sense to pass references if you intend to let the function modify the item, and const references if you don't. The only time it makes sense to pass a pointer is if the thing can be NULL and the function is ok with handling that.

Share this post


Link to post
Share on other sites
eq    654
Quote:
The only time it makes sense to pass a pointer is if the thing can be NULL and the function is ok with handling that.


I would add something like this:

"..and when the object referenced, typically is constructed as a pointer".

I.e, in DirectX all objects created are returned using a pointer, it would be rather tedious to force yourself into doing something like this all the time:


void
myFunc(const IDirect3DTexture9& tex)
{
...
tex.Update(...);
...
}

IDirect3DTexture9* texA;
IDirect3DTexture9* texB;

D3DXLoadTextureFromFile(&texA, ....);
D3DXLoadTextureFromFile(&texB, ....);

myFunc(*texA); // No need to pass a reference IMO since the...
myFunc(*texB); // ..source will almost always be a pointer.





Just my 2c

Share this post


Link to post
Share on other sites
Quote:
Original post by eq
Quote:
The only time it makes sense to pass a pointer is if the thing can be NULL and the function is ok with handling that.


I would add something like this:

"..and when the object referenced, typically is constructed as a pointer".

I.e, in DirectX all objects created are returned using a pointer, it would be rather tedious to force yourself into doing something like this all the time:
*** Source Snippet Removed ***

Just my 2c


I can see your point to a certain extent, but it really does end up making things more ambiguous. If a thing can't be NULL, then you might as well just use a reference. Allocation policy really shouldn't have much of anything to do with it.

Share this post


Link to post
Share on other sites
Quote:
Original post by eq
Quote:
The only time it makes sense to pass a pointer is if the thing can be NULL and the function is ok with handling that.


I would add something like this:

"..and when the object referenced, typically is constructed as a pointer".



Which is tipically equivalent to "if the thing can be NULL". In your example, giving wrong arguments to the texture creation functions won't create a texture.

Also, COM objects should be handled via pointers, not references, although they can be wrapped in specific objects. The reason is that they don't obey to the RAII paradigm, as their Release() function should be used to decrease their ref count. When the ref count is 0, the object is destroyed, and you have a reference that is no more valid. As a consequence, that's pretty much a bad idea to use COM objects through references.

Regards,

Share this post


Link to post
Share on other sites
kvp    196
Quote:
Is there any speed hit when dereferencing pointers?


One memory read more. But dererencing can be as much as several thousand reads/writes during object copy. (if the objects supports it at all)

What the cpu does with a pointer or a reference is that it adds the base address to the offset. With static variables this addititon is done by the linker during linking. With stack based variables, the stack frame pointer has to be added to the offset, so all stack based variables are handled like static pointers and all stack based pointers are handled like pointers to pointers to data. (two more cached reads)

The x86 architecture has dedicated address computational instructions, so with a pipelined cpu, the difference between the two should be zero.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this