What is faster....?
I've got 100 instances of a class (<-not really...just an example) each one with a public variable...I want to loop through the instances setting each variable to a certain value...
On the other hand I've got another 100 instances of a class, with a private variable and a function that can be called to change that variables value...Again I want to loop through the instances but calling the function to set the variables value...
Which method would be faster, and is there some point in the number of instances, that a certain method is just too slow to use?
Unless a function imposes some restriction on the range of values that can be set for a given variable there's no need to use one. The method which calls a member function is going to be slower, but not that much slower.
If the member function doesn't contain too much code, you can declare it inline. This will save you the overhead of a function call, plus it can reduce the size of the compiled code (depending on how much code the function contains)
So either declare the function inline if you're worried about speed or get rid of the function completly if it doesn't impose any restrictions on private/protected variables.
Although, in my limited (and quite limited at that) knowledge, modern day compilers are very good, and often or not compile functions if they think they are deemed appropriate. Also when using the inline function, as far as I know its simply a request to the compiler to make it inline, it doesn't have to at all...although, if I'm mistaken please let me know! :). So I think the compiler would probably make a function that is simply setting the value of a variable in a class, inline.
"The method which calls a member function is going to be slower, but not that much slower."
If I had a few thousand objects then, would the speed drop be noticable?
Thanks for your comment!
The speed drop will be noticable as soon as you start doing a lot of operations to those variables. A call to a function involves overhead as variables are pushed to the stack, the function is called, and the variables are popped back off the stack. Inline is just a request, but put it there. The compiler will be more likely to make it inline if you stick that keyword there than if you don't.
Your best bet is to use the function; it encapsulates the data better.
Function call overhead is quite minimal. Your best bet is to write the code, then evaluate its performance -- learn not only how long it takes, but what part of that time is each given section of code.
You rarely bottleneck where you think you do. Further, what performance is acceptable depends a lot on the application.
"then evaluate its performance -- learn not only how long it takes, but what part of that time is each given section of code."
how would I go about doing something like that? (I'm not wanting code, just general idea)...
There are professional code profiling tools, or you can use OS-specific precision timers; Windows has some which can easily have much better than millisecond accuracy.
"Windows has some which can easily have much better than millisecond accuracy."
Now THAT is really pushing for efficient code!!!
Function call overhead has a (relatively) fixed price. This means that the slowdown from a function call will be much more noticeable in small functions that are called very frequently, than with longer functions or those called infrequently.
I'm not saying don't use functions to hide data though. Definitely take Cat's advice.
What I would suggest though, is try to stay away from direct accessor methods (perhaps as protected members, but not public members). If you do need them, perhaps you should rethink your class design.
Knuth teaches us that "premature optimization is the root of all evil".
Program using proven techniques and practices. Then if there is a problem with speed, determine where the bottle neck exists (which is often not where the programmer suspects) and concentrate on that part of the code.
I totally agree. Profiling should be done after the program has finished. First develop good code, then if necessary optimize it. It is usually a very small part of the code which takes most of the time.
Keep optimization in mind while writing your code (make sure you use the proper algorithms, and don't intentionally make things terribly un-optimized), but avoid inlining until you can use a profiler. I read some articles recently (though I can't find them at the moment) that show that careless inlining can lead to a reduction in performance in some cases.