Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 11 Aug 2012
Offline Last Active May 02 2013 02:18 PM

Posts I've Made

In Topic: Google Play restricting devices

02 May 2013 - 01:11 PM

The Google Play store already has a built in option where you specify what DisplaySize you want to target.

Uncheck the medium one, or google it further

In Topic: Simple & Robust OOP vs Performance

10 September 2012 - 07:17 PM

Thank you guys for all the replies, all are very helpfull and interesting to read.

In Topic: Simple & Robust OOP vs Performance

06 September 2012 - 04:59 PM

1 class with 100 methods VS multiple classes with a few methods is not really about performance but more about sensible design.

Why do you think one "mega class" would perform better?

From developer.android.com best practices:
"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."

Thus, you should avoid creating object instances you don't need to..

Unless I'm wrong, having 1 class with 100 methods, over 1 class, and 10 subclasses, each one having 10 methods, will result in
1 object vs 11 objects

What do you mean with sensible design?

How can you optimize code without profiling? How can an optimization be effective if you don't know whether you're dealing with a bottleneck or not?

I've worked on some larger projects myself, and I can tell you for sure that premature optimization is something you definitely want to avoid.

Write your code according to the proper standards. If you're working with OOP then make sure you properly follow the rules of an object oriented design. A class with 100 methods is definitely a serious violator of the single responsibility principle, which is an enormously important concept within OOP.

If you find that you're having performance issues after following the proper standards you should not resort to micro-optimizations, but you should look at optimizations at a larger scale. Rewrite algorithms which pose a bottleneck, go over some larger systems and see which components could be altered to run faster, etc.
If this still shows performance problems you should probably consider whether it's the design itself which just isn't optimal for the problem you're trying to solve, micro-optimizations should be at the very end of the optimization progress when every other step did not provide a proper solution IMO.

My point was to explain my realization about the fact that you can't follow a guide line or best practices all-in;
You need to make a balance, you should profile your application, but not be naive about optimizing your application at some extend.

An example of micro-code optimization, without profiling first

code not micro-optimized (java):


//A random ArrayList of an object
ArrayList<AnotherObject> arrayList = new ArrayList<AnotherObject>(100);

//A vector we will be using
Vector3D utilityVector3D = new Vector3D(0,0,0);

for(int i = 0; i = arrayList.size(); i++)
AnotherObject obj = arrayList.get(i);

utilitVector3D.x = obj.x;
utilitVector3D.x = obj.y;
utilitVector3D.x = obj.z;


code micro-optimized:


//utilityVector3D is not a member of the parent class of the method
//--- Comented, instantiated at the constructor Vector3D utilityVector3D = new Vector3D(0,0,0);

//A random ArrayList of an object
//--Commented and instanciated too --ArrayList<AnotherObject> arrayList = new ArrayList<AnotherObject>(100);

final int sizeList = arrayList.size();

for(int i = 0; i = sizeList; i++)
final AnotherObject obj = arrayList.get(i);
utilitVector3D.x = obj.x;
utilitVector3D.x = obj.y;
utilitVector3D.x = obj.z;


Here you choose to avoid the Garbage collection to happen at the expense of some Memory.

My point was that it is good to do some micro-code optimization now and then, but at the same time balance by using simple and robust objects, as my pointed example of the 1 object vs 11 objects above.

Am I wrong?

In Topic: Simple & Robust OOP vs Performance

06 September 2012 - 04:32 PM

Basically you summed it up.

Language features do have a cost, you need to be aware of those costs.

Make it work (first pass development). Make it work well (debug). Then make it work fast (optimize). In that order.

You point out in your example that you were able to fit a tiny bit more data into your game. But what is the cost? It takes longer to develop initially, is more difficult to debug, and more time consuming to maintain.

You need to know and understand the tradeoff. Is the very slight reduction of gameplay performance worth the cost to develop the software? That's a business decision, but generally the tradeoff is made in favor of faster/cheaper development.

For example, virtual functions were scoffed when they were introduced in the 1980s. People (correctly) pointed out their performance cost, and (incorrectly) calculated the performance cost as though every function were virtual. Hopefully it is obvious that it is unwise to make every function virtual because there is overhead (roughly 15ns per function call on current hardware), but that doesn't mean virtual functions are bad. Used properly virtual functions solve a problem and generally offer better performance than trying to write your own solution.

Know the cost and use the feature properly.

you need to save time by optimizing parts of the code (assuming you have a good code design) by the very beginning, in parts where you do know that you will have a performance boost

Knuth's saying was that premature optimization is the root of all evil. Wait until you have written it and profiled it before changing it, and make sure you measure afterword to verify your changes improved things.

But that doesn't mean you should intentionally write pessimistic code when you know something is performance-intensive. If you know something will be resource heavy you should plan for it accordingly. That is NOT a premature optimization.

I agree. And I assume you code in C# :)

In Topic: Weird Bug I found: Randomly crash your activity, for some reason, activity re...

06 September 2012 - 04:22 PM

It seems like the CACHE gets full.

Call webview.clearCache(); and webView2.destroyDrawingCache() now and then.