besides, map.get(x,y) isn't all that complex compared to map[x][y]
.
You can do better, because () can be overloaded on the whole class:
map(x,y)
although it's an implementation detail that really shouldn't make a difference.
Well it will, because of memory caching. If you are processing a whole map, then you should do so with the "grain" of memory, rather than against the grain to take advantage of caching. That can mean a 10-20x speedup between implementations, and the only difference is whether you put the x-loop on the outside or the y-loop. People trust the magic of the "compiler optimizations", but the compiler doesn't do all the things that people think it does. If you e.g. have a useless variable used in an inefficient way, the compiler leaves that variable in place doing the job you told it to do - it's not a magic "shitty code fixing genie". A lot of "proper" OO ways of doing things are super-inefficient, in ways that compilers can't fix.
Bools are basically the worst data type in the world to put in a class for example. If you have an int, a bool and then an int. Then the bool will take up
4 bytes, because the compiler needs to align the next int on a 4-byte boundary to allow for faster memory access. That's the "optimization" it makes to handle the shitty memory layout you specified. But those bools and their padding end up making data structures much bigger, so you can't load as many of them as possible per memory-cache-read. So, e.g. the very worst thing you could do would be to stick a "bool active" in the middle of a data structure, then cycle through all data structures and only do an action to the "active" ones. Huge amount of wasted space with padding, and with memory cache reading of ALL the data from each and every game object in the array. The faster and more memory efficient system would be to instead have a
separate "active" array of bools, cycle through that and then only load the actual data structures for the "active" ones.
So, yeah, over-object-orienting things is like normalizing databases to 4th normal form. It's good on paper, but leads to an inefficient clusterfuck.