7

What are the differences and pitfalls between reusing instances of objects vs creating new ones, every time I swap buffers?

Background:

This is for a game engine project of mine.

I am writing a TripleBuffer where I have three versions of every object: an old version, a current version, and a future version. Changes on these objects will be made by reading state from the current version of it and applying changes to the future version. After changes have been made to all objects (resp. where applicable), the buffers will be swapped: the future objects become the current objects, the current objects become the old objects, and the old objects?

  • either get discarded and new objects will be allocated by iterating over the now current objects
  • or become the now future objects and their values will be updated (resp. overridden) by iterating over the now current objects.

Explanations:

  • "reusing": overwriting the values of an old instance with new values, effectively changing the state of the instance
  • "new ones/cloning": creating a new instance using the data of an old instance, and applying changes to it

Use Case:

Say some 1000 objects are swapped at 30Hz, meaning they need to be recreated 30 times a second by either cloning the now current ones or by reusing the now obsolete last old ones (overriding all their state).

They can range in complexity from some 5 properties up to hundreds of properties and will always have a depth of at least 2 levels.

(depth of at least 2 levels = the buffered objects will themselves only contain a map of other unique objects that make them up)

Recreating as well as reusing will both require to iterate over the current objects and their components (shorter than: the objects that in turn make them up).

Further considerations:

In other parts of the engine there will be event firing and other magic that will do work using in-time snapshots of the objects. Hence the decision of recreating or reusing will lead to either:

  • recreating means I can safely pass on references to the object, as the object will become immutable at the time it becomes a current object
  • reusing means I will have to create copies of the current object or whatever part of it I further need, as I cannot guarantee that the event (or whatever) will be processed before the object gets reused
dot_Sp0T
  • 389
  • 4
  • 26
  • how many objects are you dealing with at a time? how expensive is to create( like how many properties they have .. how long does it take for your constructors to initialize, how much time they are going to be "valid" --i.e. how frequently you update them )?.... Generally , I suggest to avoid "re-using" unless they are immutable... b/c you are at risk of data corruption .. Are you trying to come up with garbage collection Strategy? – Sendi_t Apr 29 '15 at 15:18
  • Writing "well performing" code is generally a good thing; but keep in mind: unless you are talking about time-critical, high-performance computing applications ... don't worry about performance. Instead: try to write code that is easy to understand and maintain. In that sense: if objects are **immutable** (their inner state is "fixed" after creation); you avoid many problems regarding thread-safety for example. Thus I would tend to avoid "reusing" anything; unless you are talking about millions of objects here. – GhostCat Apr 29 '15 at 15:20

2 Answers2

10

Unless you have a very good reason to do otherwise, discard the old objects and create new ones.

This will reduce your chances for various bugs. For example, if there's a reference to the old object somewhere else, re-using it may have bad side-effects. Discarding and creating new objects is cleaner conceptually and would probably make the code easier to read, debug and maintain.

In the general case, the garbage collector is also smart enough to make discarding and re-creating object not that expensive.

What I would do in this situation is write the clearest, most straight-forward code, which means creating a new object whenever I need it. Then I would test it to see if that's a performance bottleneck, and only if it is, I would look at optimization. In other words, I would try to avoid premature optimization.

Community
  • 1
  • 1
daphshez
  • 9,272
  • 11
  • 47
  • 65
  • One of the issues here (and I agree on the subject of premature optimization) is, that this decision pretty much dictates about how the rest of the codebase will be built up; will add an example/use-case – dot_Sp0T Apr 29 '15 at 16:53
1

A buffer is used in Graphics so that you are not "drawing" to the screen pixel by pixel as you attempt to update it. Instead, you draw to the buffer, and then you can swap the entire image all at once.

I assume there is a similar reason why you are using a buffer. You don't wish to modify "current" objects with newly updated ones as you work through them because it will disrupt the "image" of the current objects.

Advantages of reuse:

  • You are not discarding as much memory, requires less garbage collection
  • You only need to update objects that have changed

Advantages of re-creating

  • Every object has to be created
  • Simpler and cleaner

Your ultimate decision will be based off performance vs clarity. How expensive is it to recreate all of your objects? Is it cheaper to compare between each of the objects and only build the ones that are needed?

Even if it is cheaper to compare objects or keep track of which have changed, it might be worth the cost of creating new just for more simplicity, which is exactly what @DaphnaShezaf's answer is about.

Community
  • 1
  • 1
DoubleDouble
  • 1,493
  • 10
  • 25