0

I plan to create a representation of a 2D (topographical) map in Android (3.0) in the following way

  • a class MapCoordinate, which is just a 'struct' and consist of public attributes x,y of type int and represents a MapCoordinate
  • a class MapPoint (not a good name probably), which encapsulates methods to access and alter data of a point in a map (for one map coordinate)
  • a class Map, which has one instance / Map (there is only one in my app) and encapsulates a Map by having a HashMap:

    public class Map {
        HashMap<MapCoordinate, MapPoint> mapPoint = new HashMap<MapCoordinate, MapPoint>();
    }
    

So, my question would be: Is it performance-critical to have many (Java) object instances on Android (only tablet PCs are the target of my app). Of course this map is only a tiny fragment of my whole application. The map can get rather large.

Thanks for your feedback.

Durandal
  • 5,575
  • 5
  • 35
  • 49
Marco
  • 2,189
  • 5
  • 25
  • 44

1 Answers1

2

You could try to implement the Fly Weight pattern if possible. Official documentation recommends avoiding object creation:

Avoid Creating Objects

Object creation is never free. A generational GC with per-thread allocation pools for temporary objects can make allocation cheaper, but allocating memory is always more expensive than not allocating memory.

If you allocate objects in a user interface loop, you will force a periodic garbage collection, creating little "hiccups" in the user experience.

Thus, you should avoid creating object instances you don't need to. Some examples of things that can help:

  • When extracting strings from a set of input data, try to return a substring of the original data, instead of creating a copy. You will create a new String object, but it will share the char[] with the data.
  • If you have a method returning a string, and you know that its result will always be appended to a StringBuffer anyway, change your signature and implementation so that the function does the append directly, instead of creating a short-lived temporary object.

A somewhat more radical idea is to slice up multidimensional arrays into parallel single one-dimension arrays:

  • An array of ints is a much better than an array of Integers, but this also generalizes to the fact that two parallel arrays of ints are also a lot more efficient than an array of (int,int) objects. The same goes for any combination of primitive types.
  • If you need to implement a container that stores tuples of (Foo,Bar) objects, try to remember that two parallel Foo[] and Bar[] arrays are generally much better than a single array of custom (Foo,Bar) objects. (The exception to this, of course, is when you're designing an API for other code to access; in those cases, it's usually better to trade correct API design for a small hit in speed. But in your own internal code, you should try and be as efficient as possible.)

Generally speaking, avoid creating short-term temporary objects if you can. Fewer objects created mean less-frequent garbage collection, which has a direct impact on user experience.

Cristian
  • 198,401
  • 62
  • 356
  • 264
  • This article is referring to avoiding unnecessary short-lived, temporary objects which will constantly be created/GC'ed. It seems to me Hawk66 is worried about having too many objects in a long-lived HashMap which is an entirely different concern? – dbyrne Feb 15 '11 at 20:20
  • Yes, the fly weight pattern might partly fit. as dbyrne mentioned, the hash map is supposed to live more or less the whole life-cycle of the app. NDK I only wanna use as a last resort. – Marco Feb 16 '11 at 17:37