0

I'm currently writing a game in Java, and I'm trying to make a few simple design decisions that will reduce memory usage from the get go (to prevent from having to make large changes later to reduce memory usage). The main layout of the game will be a hex grid, and I'll be using a HashMap to store the hexes in. Each entry is going to have a Point object as the key, and a Hex type object (Hex is an interface) as the value. I'm going to have two different objects that implement Hex; OceanHex and LandHex.

While LandHex is going to contain a lot of fields (buildings, stats, players currently on the tile), players will not be able to build on or move onto the ocean tiles. Essentially, they're just aesthetic. For this reason, OceanHex is only going to contain 2 static final members, making each instance of OceanHex the same. I originally planned to cut down on memory usage by only instantiating one OceanHex instance and having each ocean tile reference that instance, but this got me curious. Since OceanHex only contains static fields, would many instances of OceanHex actually use more memory than a single instance?

In general, my question is: for a class that only contains static fields, would having many instances of the object take up the same amount of space as having one instance of the object with many references to it?

I'd imagine creating instances of classes with only static fields is rare, but I'm curious nonetheless.

Thomas
  • 1,123
  • 3
  • 13
  • 36
  • Each additional object will still take up *some* memory, but not as much as if the fields were instance fields. But it's definitely more correct to create a singleton instance than creating a bunch of instances with static fields. – shmosel Mar 20 '17 at 23:17
  • 4
    My advice is: make your design simple, correct and easy to navigate and more often than not memory usage will take care of itself. If it doesn't, rewriting it will be easy. If you start out with a horrible design, things will only get worse. In this specific case, making `OceanHex` a singleton makes perfect sense, not because of any memory footprint considerations, but the simple fact that in your world all ocean fields are logically equivalent. – biziclop Mar 20 '17 at 23:32
  • By the way, the approach you mentioned about using a single copy of the `OceanHex` is the *Flyweight* design pattern, and makes sense if every "instance" if a particular concrete class is indistinguishable. – chrylis -cautiouslyoptimistic- Mar 20 '17 at 23:38

3 Answers3

3

While every instance does use memory it will be negligible on most machines (see this question for details). The only times you should consider introducing complexity (such as a singleton) to avoid memory usage is when you are running on very limited hardware or you are intending to have very large numbers of the objects. I doubt either of these will be true for a game. Go for simple, clear code first and then look to optimise resources later if you have an issue.

If you do decide to share your instances I recommend you take a look at the Flyweight Design Pattern for implementation details.

Community
  • 1
  • 1
sprinter
  • 27,148
  • 6
  • 47
  • 78
1

Regardless of whether you instantiate a single instance or multiple, you will always have the same number of references. Either many pointing to the same object or many pointing to many objects.

Since the number of references are the same, the question really becomes: Do many objects use up more memory than an single object.

The reason the static nature does not really matter is because you would still be instantiating objects which all have at least a header and a GC footprint.

So the answer is: yes more objects mean more memory used.

Hangman4358
  • 411
  • 1
  • 4
  • 11
0

Yes, each instance will take memory.

Think of it this way instead: Everything inherits from Object. Therefore, every time you make a new instance of something, it, at the bare minimum, is an instance of an Object.

Christopher Schneider
  • 3,745
  • 2
  • 24
  • 38