android, object oriented programing vs designing for performance

I am a complete noob to android but I have been programing c# for a long time. I am writing an android application and have gotten to a point where the c# programmer in me wants to start creating a loosely coupled design an开发者_如何学JAVAd and moving code into different layers, using interfaces, etc.

But then I stumble upon the Designing for performance guidelines it is telling me to avoid object creation and then it also is saying to optimize judicially.

Do I just build based on good design and then deal with performance issues as they come up?

The last thing I want to do is go through the work of building a application and have it perform poorly. Can someone point me to some examples of application that are designed well and have good performance or just make some recommendations?

Thanks

I've found AndEngine to be fairly well designed and it has to be concerned with performance since it is a game development library -- so you might pull down a copy of it and read the source.

In the "Designing for performance" document, I would point out this statement:

Note that although this document primarily covers micro-optimizations, these will almost never make or break your software. Choosing the right algorithms and data structures should always be your priority, but is outside the scope of this document.

An example of this would be creating a particle system. A good way to model it is to have a ParticleSystem object that holds a collection of Particle objects...maybe those Particles implement a Particle interface...this is not the place to avoid object creation. However, for performance reasons, you will want to optimize the ParticleSystem to recycle Particle objects rather than creating them from scratch every time you spawn one.

Personally, I haven't found performance to be much of a limiting factor but I suppose that will really depend on what type of app you're building.

My opinion is to build a suitable design first, test the performance, and optimize from there.

Pay more attention to Donald Knuth's quote that appear in the same article:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.root of all evil."

Then if you are dealing with the other 3% you'll see...

As a general rule, the thing to do is keep the data structure as simple and normalized as you can. Like don't just throw in hash table data structures just because they are easy to grab. Know how to do profiling (here's my method) and if you have a real performance problem then fix it. Otherwise, the simpler the better, even if that means simple arrays, lists, and O(N) loops.

The reason to keep the data structure normalized is, if it is not, then it can have inconsistent states, and you will have a strong temptation to write notification-style code to try to keep it consistent. Those can be real performance killers. If you do those, the profiling will tell you it that's what is happening. If you must have redundant data, I think it's better to be able to tolerate some temporary inconsistency, that you periodically repair by passing through the data. This is better than trying to intensely guarantee consistency at all times by notifications.

Another problem with unnormalized data structure is it can have lots of object creation and destruction. That also can be a real performance killer, although you can ameliorate it with the pool technique.