1

I constructed a class Vector some time ago which I use quite frequently. As time goes by I'm adding more and more methods that are fun and useful, such as normalize, projection et cetera. The class starts to get quite big and will presumably get even bigger.

As I'm using this class to calculate positions and movements of 1000+ objects and am creating new instances every 1/60 second, I'm starting to worry that performance and/or memory might be an issue.

I've tried to look for answers on Google but only found this which refers to C++, but maybe the answer still apply?

Otherwise my questions are: Is there any significant performance issues? Should I try make my class smaller and create functions instead? Are there other significant downsides for using big classes that I should be aware of?

Community
  • 1
  • 1
Ted Klein Bergman
  • 9,146
  • 4
  • 29
  • 50
  • You should consider usage and simplicity, rather than performance. Are these extra methods always used or are they specialised? Would your design be better if some of the extra goodies were in derived classes? Are they even tied to the class anyway (consider normalisation applied to code)? Would they fit better inside another class (a mixin) so the fun stuff can be reused? Keep It (your class) Simple. – cdarke Jul 14 '16 at 08:13
  • I do consider usage and simplicity in first hand but I'm still curious about the performance impact. I like the way the class is designed and every method is tied to the class. But many of them are specialized so converting those methods to function wouldn't be such a big deal if it improved the performance by any important amount. – Ted Klein Bergman Jul 14 '16 at 08:21
  • OK, the layout of byte-code in memory will be very implementation and version specific. But consider that a whole module is compiled and loaded when it is imported. A derived class in another module containing specialised methods need not be imported (and therefore compiled and loaded) and so would only give an overhead when required. The code can be structured into packages (a directory tree). You need to benchmark with your own code to see if there is a significant performance difference. It will depend on volumes. – cdarke Jul 14 '16 at 08:43

1 Answers1

2

The (code) size of a class does not has a (direct) performance consequence.

Also, as long as you don't have or expect performance problems, don't focus on optimization (mostly optimization results in more work, and sometimes more unreadable/maintainable code). Only optimize for performance if needed. Initially, always concentrate on small classes/readability/maintainability. Especially the last seems important since you add regularly functionality.

You already give some function areas, like projection, normalization. Maybe you can move them to other classes, or helper classes if they do not need any data.

Also maybe you can split your classes using inheritance, if there are some specific vector types, or maybe you can use the strategy pattern to perform different types of algorithms. But maybe you just have hundreds of functions you can use on a vector; in this case use helper methods, pass the vector with it and put each method in the best helper class.

like e.g. for normalization:

public abstract VectorNormalization
{
     public void Normalize(Vector v)
     {
        .. do something with v
     }

     public void NormalizeDifferent(Vector v)
     ...
}

And you can call it by

Vector v = Vector(3,4);
VectorNormalization.Normalize(v);

About the performance. To call the Normalize function:

  • Normally a helper class uses internally a so-called v-table. To call a helper method, the compiler needs to add the v-table start to the function and call it, this is a very negligible performance loss. I think C++ and Python work very similarly.
  • In addition the stack needs to be filled with the vector.
  • The function call is made.

Only the first will be changed, since in a big class the 2nd and 3th will be needed too.

You can win performance wise probably much more by optimizing the algorithms themselves wherever needed.

Btw,

Michel Keijzers
  • 15,025
  • 28
  • 93
  • 119