1

I have come across the term "garbage disposal" and now I'm worried about using up too much memory. Apparently (correct me if I'm wrong) every time an object is created, memory is reserved for it, and that object must be properly disposed of if not needed anymore. My question is if one should avoid instantiating objects then whenever possible. For example, if a function requires a coordinate as arguments, should I have

example(int x,int y)

or is it okay to have

example(Point p)

and during the actual call I do something like

example(new Point(5,5));

I'm worried about not slowing down the application, so I would like to know if having primitives as arguments is better than having objects which will usually be instantiated on the spot

6

now I'm worried about using up too much memory

You are not talking about a real program, just some "feeling" your programs might use up too much memory? Why? Ask this question when you have a written a program which uses too much memory, not beforehand.

My question is if one should avoid instantiating objects then whenever possible

Short answer: no, not "whenever possible", not "most times", maybe "in some rare cases". The decision to create classes and objects should be guided first and almost by the question if they form proper abstractions for your task or algorithm. Performance or memory optimizations on that level you have in mind should be done when needed, never beforehand.

should I have example(int x,int y) or is it okay to have example(Point p)

Actually, that example might be a little bit misleading, since it will lead to calls

 example(new Point(5,5))

vs.

 example(5,5)

and the latter one looks more readable than the first on a first glance. In a real world program, however, you will probably not have to write something like example(new Point(5,5)) too often, instead you have to process a set of points in a way like this:

foreach(Point p in setOfPoints)
   example(p);

which is more comprehensive than example(p.X,p.Y). And if you have really lots of calls with hard-encoded literals like example(new Point(5,5)), you could provide both example variants as some syntactic sugar. Note that the primary question here is "what makes the program more readable?", not "does this make a slight difference in memory usage on a micro scale level?".

Imagine what happens if you have lots of functions with more than one Point parameter, like

 bool doPointsFormATriangle(Point p1, Point p2, point p3)

vs

 bool doPointsFormATriangle(double x1, double y1, double x2, double y2,double x3, double y3)

you get twice the number of parameters in the second case, and readability of calls to that function decreases by the same factor of two.

Indeed, where I work, I still have to maintain some older programs which were written by a beginners guy some years ago in the style like the second doPointsFormATriangle, with hundreds of function calls passing all 3D points as primitive coordinates. From that experience I can tell you its horrible - so do yourself a favor and avoid that style.

  • I think the use of Point is fine, assuming you use Point, and not break it down into its x and y primitives immediately afterwards. That would mean creating an instance only to not use it is somewhat silly. Consider also that Point can always be extended to include useful calculation methods with other points in the future. To achieve the same effect with integer parameters, you'd have to create the instance in the method that requires these calculations. – Neil Mar 25 '15 at 8:36
  • @Neil: what you write sounds like the signature of the function example should depend on its implementation. If that is what you meant, I disagree - the signature should depend on what the callers need most, not what is easier to implement. If the example function is implemented in using primitives, it may be another reason to provide two variants, one with (x,y) (which may contain the calculation code), and one example(Point p){return example(p.X,p.Y);}. – Doc Brown Mar 25 '15 at 10:39
  • What I mean was that if the purpose of Point is purely to pass a parameter to a method, I have to question the usefulness of Point. However, you should generally tend to prefer the use of objects like Point over passing two primitives, but only if you intend to make use of Point. This is, afterall, the scope of object-oriented programming in the first place. If your library is going to accept Point just to take the x and y components and put them in some array immediately afterwards, you shouldn't accept Point at all. – Neil Mar 25 '15 at 11:00
  • 2
    @Neil: as I wrote, this is about proper abstractions. If you create a library dealing with a "point abstraction", you should provide a class Point and design your API around that, and it does not matter if a function of that lib stores the components x and y in separate arrays internally. – Doc Brown Mar 25 '15 at 11:04
6

It really depends upon the programming language, and the implementation. Read also Scott's book on Programming Language Pragmatics.

Read the wikipage on garbage collection (GC). GC can be quite efficient, read A.Appel old's paper: Garbage Collection Can be Faster than Stack Allocation and for a good overview the GC handbook

Some programming languages, like C, don't even have any objects, and require manual memory management, read more about C dynamic memory allocation.

C++ is slightly better, notably because it has programming idioms like RAII and because of its destructors (implicitly called at end of block).

Java is compiled to JVM bytecode which generally has quite a good GC.

Functional languages like Ocaml, SML, Haskell, Common Lisp implementations (and most JVMs) usually have good generational GC which handles differently fresh values or objects and older ones.

When coding, favor readable and maintainable code and efficient algorithms. Remember the adage that premature optimization is evil (the compiler is optimizing quite well, and could even optimize example(new Point(x,y)) as example(x,y) in some cases). If you really care, profile and benchmark your application then put your recoding efforts on small hot spots. Don't worry!

  • 2
    Your last paragraph should be on top, really! – Doc Brown Mar 25 '15 at 6:41
  • For Java, Java theory and practice: Urban performance legends, revisited may also be a useful reference. Even beyond the very researched gc, its quite likely that small objects don't even become really allocated if they don't escape the scope (or they may be allocated on the stack instead and allow the stack frame to clean them up rather than garbage collection in the heap). – user40980 Mar 27 '15 at 2:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.