Sign in to follow this  
Merlino

Performance question with classes and functions

Recommended Posts

Hi, i have one fast question: imagine that you need a class that has many objects and you also need several functions that modify the object's values. Do you get a better performance if you create one class with all the functions and another one with the values and only create one object for the function class OR is it better to create just one class with the values and the functions and create all the objects for it? Example: -- Case 1 --
class number
{
   private:
   int value;
   int halfOfTheValue;
   friend class handle;
}

class handle
{
   public:
   divideBy2();
   multiplyBy3();
   setTo0();
}

main 
{
number * 1, *2, *3, *4.....;
handle * Handle;
}


-- Case 2 --
class number
{
   private:
   int value;
   int halfOfTheValue;
   public:
   divideBy2(number * Number);
   multiplyBy3(number * Number);
   setTo0(number * Number);
}

main 
{
number * 1, *2, *3, *4.....;
}


I think case 2 is better but I am not sure, that's why I'm posting. THX :D

Share this post


Link to post
Share on other sites
1) You shouldnt be worrying about performance unless you have profiled your code :-)
2) Case 1 reduces readability and is counter intuitive
3) case 1 uses 5 extra bytes of memory :O (depending on hardware/OS/compiler this may vary)
4) yep Case 2 is better for the above reasons unless you know from PROFILING your code that it is necessary to optomize this bit of code
5) From a purly theoretical perspective Case 2 should be faster (it avoids a dereference to call the functions :-))

Hope that helps
Sorry if sounded a bit harsh but this screams "premature optimization" IMHO :-)

Share this post


Link to post
Share on other sites
Well, it doesnt make too much sense to seperate the data and the functions like that, if you are going that way you might as well use C or something, and use non-member functions with pointers-to-structures as arguments.

Your classes seem a bit disjointed, why does (in the second one) number::mulitplyBy3() etc take a "number *" as a parameter?

Does one invoke it using "numberPtr->mulitplyBy3( numberPtr );" ?

Why doesnt it make use of the "this" pointer already passed to it?

How does the handle class perform the operations on a number? Does it have a number internally as a member, does it refer via a pointer to a seperate number object, should its member functions take some number reference as a parameter?

I would recommend you post the code you are actually concerned about, so we have something more concrete to discuss. Your example as is is quite confusing.

You seem to be using lots of pointers too, even when its not required. Why aren't the numbers in main() allocated on the stack, like so:


int main()
{
number one, two, three; // etc
}



The chances are that you would use the second one. It makes more sense anyway.

Share this post


Link to post
Share on other sites
HANG ON,

I just reread that

Quote:
class number
{
private:
int value;
int halfOfTheValue;
public:
divideBy2(number * Number);
multiplyBy3(number * Number);
setTo0(number * Number);
}


why is divideBy2, multiplyBy3, and setTo0 taking pointers to numbers? they are member functions of the class number so they already take pointers to themselves, unless im not getting what they are meant to do what youve got there implies that you say this

number aNumber;
number anotherNumber;
aNumber.divideBy2(anotherNumber);

and it will halve the value of anotherNumber. I think what you want is

class number
{
private:
int value;
int halfOfTheValue;
public:
void divideBy2();
void multiplyBy3();
void setTo0();
}


so you can say

number aNumber;
aNumber.divideBy2();

and it will halve aNumber

Or maybe im just completly off track with what you meant, im not sure :-).

Edit: i see Rip-off beat me to it im just to slow ;)

Share this post


Link to post
Share on other sites
I don't see why you would want to create a seperate function class - member functions don't take additional memory per class instance, unlike member variables. Even if there were memory benefits and such, the counter-intuitive design of it would give you other problems to worry about, like bad maintainability.
Besides, you can always create non-member functions...

I'd say, don't worry about things like that unlike you hit a wall somewhere. The wall you're likely going to hit if you do things like this is that of bad design. Which often has much more effect than non-optimal lower level code. Take a look at sorting algorithms for example (bubble sort, fast sort, etc.). The most gain is made by taking a different approach, not by rewriting an existing algorithm in pure, hand-optimized assembly. Get the idea? :)

Share this post


Link to post
Share on other sites
EDIT: I was too slow, and you revised your post somewhat, but I'm gonna leave my post because the assumption I talk about making generally seem to coincide with what you actually revised your post to be.

Quote:

imagine that you need a class that has many objects and you also need several functions that modify the object's values. Do you get a better performance if you create one class with all the functions and another one with the values and only create one object for the function class OR is it better to create just one class with the values and the functions and create all the objects for it?


Your question does not make much sense, and your example cases are not legal code, nor do they appear to do anything useful, so there is no accounting for any kind of "performance" issue here -- what potential performance issues might arise from the legal code corresponding to what I think you're trying to do in both cases are completely insignifigant. From a performance perspective, this is a non-issue. Waste no more time thinking about it.

From a design perspective, a seperate collection of free functions, or a seperate class, designed to manipulate an instance of another class (as your case one seems to attempt) is very entirely counter to the idea of object-oriented design. Even if you don't much care to be building your program in an object-oriented manner, case one is pointless from a procedural standpoint as well. "handle" is just a container for functions, you may as well just make them free functions.

From a sane, object-oriented design position, case one is certainly the better approach (again, there is zero worthwhile performance impact).

Quote:

4) yep Case 2 is better for the above reasons unless you know from PROFILING your code that it is necessary to optomize this bit of code

Structured correctly (as in, legal functioning code), there is unlikely to be any performance impact whatsoever. The differences will likely be too small for even a profiler to pick up.

Quote:

5) From a purly theoretical perspective Case 2 should be faster (it avoids a dereference to call the functions :-))

To call the function? A static dispatch (i.e., call of a non-virtual method) does not require a pointer dereference. The address of the method is fixed and known by the compiler at compile time.

A pointer dereference is needed to access data of a particular instance, but this "overhead" (note the quotes) washes away because it needs to be done in either method (free function or class method).

Share this post


Link to post
Share on other sites
There's no point in you worrying about performance for such little things. You're most likely too new to programming to be able to make any significant positive impact on the performance of any program.
You should instead be concentrating on getting it correct.

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