Pointer Dereferencing Cost

Started by
8 comments, last by iMalc 18 years, 3 months ago
Whats a way to calculate the performance hit im taking by using pointers as opposed to a static structure of some sort ?
Advertisement
Usually it costs an extra memory access because if the data is on the heap there is a higher chance that it won't be on the same page. But if you dereference it again and that page is already in cache, then it would be the same speed as the static structure.

Well, ask yourself this: "Is it too slow right now?"
The way to find the performance hit is with a profiler. Doing performance estimations based on pure theory is not useful for such tiny operations on modern computer hardware (theoretical performance is only useful when considering larger scales, i.e. big-O notation et. al.).

The only time you should worry about performance is when: 1. There is a severe and undeniable performance problem that is visible during normal use of the software, and 2. the profiler has told you what section of code is having performance problems.


Statistically speaking, there is a 98% chance that a pointer dereference is not the cause of any performance issues you have, unless you have a horribly bad arrangement like dereferencing a dozen pointers across a dozen memory pages inside your inner loop, and thrash the CPU cache. In any case, though, only worry about it if your profiling analysis tells you to worry.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

Well in response to both posts, its not that its too slow now, or that a single pointer dereferencing might be too slow. I've been toying around with a starcraft-like game for about 3 months now, just to brush up on my C++. Each playable 'object' in the game has between 4 and 8 pointers in it and i may have up to 300 of these in a game meaning i may have about 1200-2400 pointers active during the game loop, with 2400 pointers, would i notice a performance hit over static structures ?

Also I know V-tune from intel is handy, but expensive, is there a similar tool for free ?
Quote:Original post by harnacks
Well in response to both posts, its not that its too slow now, or that a single pointer dereferencing might be too slow. I've been toying around with a starcraft-like game for about 3 months now, just to brush up on my C++. Each playable 'object' in the game has between 4 and 8 pointers in it and i may have up to 300 of these in a game meaning i may have about 1200-2400 pointers active during the game loop, with 2400 pointers, would i notice a performance hit over static structures ?

Well, you haven't so far, so there's no reason to do anything differently right now. If later on you do start to see problems, then you can switch. It's not likely to save you much time to do it now, and chances are you won't need to.
Quote:Original post by harnacks
Well in response to both posts, its not that its too slow now, or that a single pointer dereferencing might be too slow. I've been toying around with a starcraft-like game for about 3 months now, just to brush up on my C++. Each playable 'object' in the game has between 4 and 8 pointers in it and i may have up to 300 of these in a game meaning i may have about 1200-2400 pointers active during the game loop, with 2400 pointers, would i notice a performance hit over static structures ?


Honestly, as said here, I wouldn't really worry about it unless you specifically see an issue. Non-game related, but a large scale biological neural network emulator I've been working on for the last few years is EXTREMELY heavy on pointers and non-native (to C++) referencing structures alike. A sample simulation could have 10,000 neurons with 50 synapses per, a load of parallel-simulation housekeeping going on the same time, all this heavily dependent on dereferencing. It's not speedy, but the hit from pointers isn't anything more out of the ordinary, there are certainly more serious bottlenecks that affect it. So I would keep going with your plan. :)



No one is impressed by a really fast program that does nothing. The first goal is a program that does something. Then once you have that if it doesn't do whatever it does fast enough you modify it to do it faster. If performance tuning the application after the fact creates major problems then you have a bigger problem than performance. Specifically a failure to write maintainable code.
Keys to success: Ability, ambition and opportunity.
Two things:
1) Pointers aren't nice, so in C++ if you can easily make something automatic instead of on the free store, you might as well.
2) If you can't easily, is there anything you can do instead other than pointers? Nope, so don't worry about it.

Pointers are a trade-off just like most things. Sure, they mean that iteration through a std::list is slightly slower than through a std::vector, but you if you need non-invalidating inserts, you're still going to use a std::list over a std::vector.
Quote:Original post by harnacks
Whats a way to calculate the performance hit im taking by using pointers as opposed to a static structure of some sort ?
Well, the thing is, it's really best to use whatever best fits the job. If any of these pointers can point to memory, or NULL, depending upon various factors, then you don't want to use a static object because it'll use memory every time. If any of the things pointed to are of variable size, then you haven't really got much you can do about having just a pointer to it.

Basically if there's any way you can think of to avoid using pointers in any of the particular situations which has only advantages over pointers, then use it. If not, a pointer is fine. People use far more pointers per object (with heaps of objects) all the time, I'm sure. Even in fast games.
Don't worry about virtual function pointers either.

In the end, it'll be the algorithms you choose which make the game run slow or fast.
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms

This topic is closed to new replies.

Advertisement