Pro's/Con's of Getters/Setters

Performance Tuning
#1

In developing Conquer, I want to make an API for it so that people can write their own AI’s to play the game. I’ve had some fun with this in letting friends make their own AI’s and let them battle it out against each other to see who has the best one, but I want to make this a bit broader in scale.

The problem is I don’t want people to cheat, and I don’t want to have to dissect their code to make sure they’re not doing anything they shouldn’t be allowed to do. For example, I want people to be able to get the number of ships on a planet, but I don’t want them to be allowed to change it.

I assume the best way is to just put in getters and no setters to handle my problems, however, do they pose a performance problem? How much does the standard compiler optimize that? It’s very important to me that this runs very fast because the computations can run for sometimes upwards to 10 minutes. Is this the best way to go? Should I be worried about how that will mess with performance?

#2

VMs should be able to inline getters… I’m not an expert on it though, so I don’t know if they do…

My thought is that you wont notice much difference if any with using getters… unless your code is so overflowing with getters that it swamps out other things… (which I find very unlikely…)

What other options have you?.. One way would be I guess to store all values of non user modifiable fields before users gets to do their AI things… and then after they’re done compare the values to see if someone was cheating… but that will require a bunch of operations also, so it might not be beneficial at all… also with accessing fields the users might be cheating without knowing…

Another way to go would be to copy all the readonly fields to it’s own class, and send that to the user… and not worry about it, since the values will never be used in the future anyway… but you need to do one copy for each player / frame… otherwise one unfortunate player could get a user modified game state…

If there are alot of players and alot of fields it might be beneficial to put the fields in an array or buffer and do a big chunk copy instead of copying all the fields one by one…

To minimize gc, you could reuse the fields objects every frame… you could even just write to it the fields that have change… that way if a player overwrites a field… he’ll only give himself trouble, as he will be reading the wrong value in the future… :wink:

#3

I personally don’t believe optimizing out getters will make much of a difference in practice. Next to 10 minutes of computation those method call are probably negligible. If calling a simple method a few times really slows down your AI code, you’ve written some pretty zippy code :wink:
I would suggest to write clean, simple code first (i.e. a getter for # ships) and profile/optimize afterwards.
Your time is probably better spent focusing on the complexity of the AI algorithms themselves.

#4

Sorry to interrupt but Kevin(Or was it the Sun employee involved in JOGL? I think he’s name is Ken?) mentioned that all simple getters and setters are inlined.
So if your getters/setters are doing simple validation + returning/setting values then they will be inlined (unless it’s deterimental(performance wise) to inline them).

Sorry guys. I made a mistake about who said it.
It was Jeff (I knew it was him but forgot his name).

http://192.18.37.44/forums/index.php?topic=10044.msg80710#msg80710

#5 

public class Planet {
     private int ships;
     private Player owner;

     public int getShips() {
          if (owner == null)
               throw new InvalidStateException("You're not allowed to know ship number of a neutral Planet, don't ask for it");
          return ships;
     }
}

This is what I’m expecting to be in for getShips(). If I have this method, I know it’s safe and no one can cheat. But I’d almost rather people check if there is an owner once, and then call planet.ships every time after that when they know it’s valid, and not have to do the if (owner == null) every single time. I’ll try it and hope JProfiler doesn’t laugh at me for having to check that every time :slight_smile:

#6

“owner = null” is one of the fastest things it’s possible to do on a computer, and you should never be even framing the question in your mind, let alone worrying about it :slight_smile:

#7

Unless people will call it and catch exception to check if planet is neutral :slight_smile:

#8

If they do that I’ll change it to call System.exit() instead :slight_smile:

#9

You should still have getters & setters, you should simply make the setter a privileged operation that includes a security manager check.

Afterall, you are going to have to have a security manager present to prevent the user code from using reflection to query (and modify) directly the internal state of your game objects.