Is it bad to use OOP?

Started by
14 comments, last by Cornstalks 12 years, 7 months ago
I have an Item object, which has multiple fields and functions, and I create over 10000 of those Item objects for each player object, and I have around 500 player objects at any one time.

If each object takes up 4 bytes, then maybe it's a bad idea to use OOP as this takes up excess memory?
Advertisement
No. Using OOP is good, if it's used correctly. It doesn't matter what programming techniques, paradigms, patterns, designs, etc. you use if you're using them incorrectly. Chances are you are have a design flaw. Or perhaps you have a unique memory requirement (there are some games that require lots of memory, so it's technically possible), which you need to design around.

The problem isn't OOP. The problem is the amount of data you are storing (and your program design in handling that data). OOP itself has pretty much nothing to do with your memory problem, as it's simply a tool to help you get the job done. It's up to you to use it correctly.

Besides, what you just described is only 20 MB of memory. Yeah, it's a lot of objects, and there's probably a way to design around this and minimize your memory footprint, but I think most computers can handle 20 MB of memory wink.gif
[size=2][ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]
Assuming you actually need all of that data, how else are you going to store it that uses less memory?

As Cornstalks says, it isn't the tool - it's in how you use it.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]


I have an Item object, which has multiple fields and functions, and I create over 10000 of those Item objects for each player object, and I have around 500 player objects at any one time.

If each object takes up 4 bytes, then maybe it's a bad idea to use OOP as this takes up excess memory?


Also, what language are you using? Different languages will impose different overheads on different OOP features.


class A {
char x;
void fn1();
void fn2();
void fn3();
void fn4();
};
class B {
char y;
virtual void fn1();
virtual void fn2();
virtual void fn3();
virtual void fn4();
};



Eg in this C++ example you can tell your compiler that objects of type A can be packed into a single byte. But objects of type B will have a function table to support the virtual keyword - and will (likely) be at around 17 bytes long. So just how 'OOP' your objects get can be quite important.
Class B instances would be 5 bytes in size on 32-bit machines. There is only one pointer-sized addition to instances of classes with virtual functions.
Embedding an instance of that class into another may cause it to be padded to 8 bytes (again assuming 32-bit architectures) if the member following the B member is 32 bits in size and standard packing rules apply.



L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid


Class B instances would be 5 bytes in size on 32-bit machines. There is only one pointer-sized addition to instances of classes with virtual functions.


Um. Yeah. Quite right.
The members in Class B are going to be padded too, so sizeof(B) would generally be 8 bytes long on 32 bit systems, and 16 bytes on 64 bit systems.

Why does each player need over 10,000 items? Are you talking about using a fixed size array? Can you use a dynamic data structure instead?

maybe it's a bad idea to use OOP as this takes up excess memory?

In this case, I'd be more concerned about how and where the memory is accessed (e.g. cache) than about the sheer size of it. But like rip-off pointed out, do you need this structure at all or might there be a better solution you haven't though of yet?
Are you sure you have 10k items?

Think about it. If you have several of the same item, and this happens often, you can make your design simpler by adding an amount variable to register how much you have of each item, saving some serious space.

I create over 10000 of those Item objects for each player object, and I have around 500 player objects at any one time.

That sounds a lot, what kind of game are you creating? I'm sure the memory consumption of the classes wont bottleneck you. 500 simultaneous players with each having 10k "items", better focus on the complexity in syncing all it through a network.

This topic is closed to new replies.

Advertisement