CODEWITHSUNDEEP
c++oop
Omar Himada
Omar Himada

Reputation: 2588

Rapidly instantiate objects - good or bad?

Note: Although this question doesn't directly correlate to games, I've molded the context around game development in order to better visualize a scenario where this question is relevant.

tl;dr: Is rapidly creating objects of the same class memory intensive, inefficient, or is it common practice?

Say we have a "bullet" class - and an instance of said class is created every time the player 'shoots' - anywhere between 1 and 10 times every second. These instances may be destroyed (obviously) upon collision.

Would this be a terrible idea? Is general OOP okay here (i.e.: class Bullet { short x; short y; }, etc.) or is there a better way to do this? Is new and delete preferred?

Any input much appreciated. Thank you!

Upvotes: 2

Views: 356

Answers (4)

Shahbaz
Shahbaz

Reputation: 47543

The very very least that happens when you allocate an object is a function call (its constructor). If that allocation is dynamic, there is also the cost of memory management which at some point could get drastic due to fragmentation.

Would calling some function 10 times a second be really bad? No. Would creating and destroying many small objects dynamically 10 times a second be bad? Possibly. Should you be doing this? Absolutely not.

Even if the performance penalty is not "felt", it's not ok to have a suboptimal solution while an optimal one is immediately available.

So, instead of for example a std::list of objects that are dynamically added and removed, you can simply have a std::vector of bullets where addition of bullets means appending to the vector (which after it has reached a large enough size, shouldn't require any memory allocation anymore) and deleting means swapping the element being deleted with the last element and popping it from the vector (effectively just reducing the vector size variable).

Upvotes: 2

Constantinius
Constantinius

Reputation: 35069

This sounds like a good use-case for techniques like memory-pools or Free-Lists. The idea in both is that you have memory for a certain number of elements pre-allocated. You can override the new operator of your class to use the pool/list or use placement new to instantiate your class in a retrieved address.

The advantages:

  • no memory fragmentation
  • pretty quick

The disadvantages:

  • you must know the maximum number of elements beforehand

Upvotes: 2

zero298
zero298

Reputation: 26878

Don't just constantly create and delete objects. Instead, an alternative is to have a constant, resizable array or list of object instances that you can reuse. For example, create an array of 100 bullets, they don't all have to be drawn, have a boolean that states whether they are "active" or not.

Then whenever you need a new bullet, "activate" an inactive bullet and set its position where you need it. Then whenever it is off screen, you can mark it inactive again and not have to delete it.

If you ever need more than 100 bullets, just expand the array.

Consider reading this article to learn more: Object Pool. It also has several other game pattern related topics.

Upvotes: 2

Dragos
Dragos

Reputation: 296

Think that with every instantiation there is a place in the heap where it need to allocate memory and create a new instance. This may affect the performance. Try using collection and create an instance of that collection with how many bullets you want.

Upvotes: 1

Related Questions