Let's say I have an object A and B that extends A.
B has global variables that are irrelevant for A (an array, and a few counters).
Since explicit casting is costly (I'm not sure how much), would it be better, from a sheer performance pov, to only create a class A and create an array only if needed so that I don't have to cast?
I guess the question is, do global variables of an object cost anything at all, even if unused?
Edit: forgot to add the most important... functions, obviously.
In recent years, inheritance is often treated like code-smell, because it can lead to different problems:
https://dzone.com/articles/is-inheritance-dead
If we talk in pure performance term, an empty array takes about 8 bytes in RAM (4 bytes store length and 4 bytes a reference, but it is a little platform-dependent: How much space does an array occupy?). So, even if you have a thousand of such objects, one array field will take approximately 1_000 * 8 bytes ~ 8 KBytes in RAM.
As you probably know, nowadays phones usually contain > 1 GByte of RAM. However, don't forget that your app usually can take from 60 to 192 MBytes of RAM (Detect application heap size in Android).
In any case, it is more than enough not to count every little field that you are adding to your class.
However, going back to my first statement, I suggest you to think about solving the problem using composition instead of inheritance, as it is suggested in Effective Java
Update
About performance, I would suggest you to read this topic: The performance impact of using instanceof in Java Are you sure that you need such type of premature optimization? Or is it more a theoretical question than practical?
Obviously, No, don't blend both classes in one class A. Never. as you mentioned, the array is irrelevant to class A. so don't put it to A.
next, in your case, downcasting is a point that tells: Wait programmer, do you want to think a little more? sometimes, there is a solution that does not need downcasting. but
Since explicit casting is costly
I don't think so. There is some benchmark and expansions that tells us, no there is no huge difference here.
expansion
benchmark
So. follow the first solution...
Since explicit casting is costly (I'm not sure how much), would it be
better, from a sheer performance pov, to only create a class A and
create an array only if needed so that I don't have to cast?
Besides the dubious claim about the cost of casting, maybe I'm misunderstanding but that raised red flags for me. If your design involves casting an object to a subclass it could probably be better designed in some other way. I can't say what without seeing more, but the need to cast is often a sign of design failure*. As Gaket suggests, composition could be better, or there might be some other change - factory pattern perhaps?
Secondly, you should only be concerned about performance if you have noticed a performance issue, or have a real reason to think there will be one. Almost anything the processor does is going to be plenty fast unless it's done many times over (like millions). Your performance issues (unless your program is unusual in some way) are most likely going to be I/O or memory. Then after you're identified a performance bottleneck, the steps to fix it are:
measure
set a goal
fix
measure
Don't leave out any steps.
*I know casting is a central part of Android programming because you have to cast Views every time you get them, and I wonder if there might have been a better way to do that, but that's what we're stuck with
Related
Yesterday, I spent 12 hours becoming a student of Traceview. I didn't even know it existed (hangs head in shame) previous to this.
Now that I've overcome the absolute shock of the data it produces, I find Traceview can be boiled down into a couple simple concepts:
Sort by "EXCL CPU TIME" to determine exactly how much usage each individual method is using in isolation.
Look at the frequency of calls and the cpu time/real time per call. Obviously higher calls should be looked into. In most of my experience, if you sort by #1 above, methods which are called too much and take too much time will also be at the top of the list (makes sense as they are also using the most CPU).
Anyway, doing these two steps above I find 3-4 methods which are always using 90% of my CPU and taking up most of the real time delays in my app. The only problem is, none of these methods are methods I wrote, they are system methods such as:
BitmapFactory methods
WebKit methods
And other system methods
This being said, is it a correct to assume that if the top resource hogs are system methods, then it must have something to do with my design of my layouts? I am at a loss as to how BitmapFactory could be so high, my layouts aren't extremely complicated, though in one Activity BitmapFactory is taking 95% of resources itself.
TL;DR - If I run a Traceview, and if I find the top hogs of resources are all system methods, does this mean it's a layout issue? Or, how else can I tell why the system method is so high as it doesn't relate directly to my custom methods.
Thank you very much,
Ryan
I find Traceview can be boiled down into a couple simple concepts:
Those concepts are not the best, IMHO.
Sort by "EXCL CPU TIME" to determine exactly how much usage each individual method is using in isolation
In particular, this concept is fairly lousy IMHO. Yes, this is useful data. However, you then need to work back up the call stack to try to figure out what is triggering this. Sometimes, it will directly be your code. Sometimes, it will be something else that you recognize that is part of the framework (e.g., onDraw() of a View). Just knowing that some random method is taking up a bunch of time does you no good until you identify what is triggering that method to be invoked in the first place.
If I run a Traceview, and if I find the top hogs of resources are all system methods, does this mean it's a layout issue?
No.
Or, how else can I tell why the system method is so high as it doesn't relate directly to my custom methods.
Work your way up the call stack to figure out who is calling these methods so frequently, or at inopportune times.
For example, in the BitmapFactory example, you will probably find that you (or a library that you are using) is calling BitmapFactory, and perhaps is doing so on the main application thread.
To work your way up the call stack, click the triangle on the left edge of the row representing some method of interest. You will then see two branches beneath that: "Parents" and "Children". The "Parents" represent the next level up the call stack from the method, and you can continue working your way up the chain of parents until you find something that you recognize.
That's why, IMHO, you are better served sorting by inclusive time, as your code (where it directly is the culprit) will tend to bubble towards the top.
Well, I found the problem and it's bitter sweet. It's sweet because it wasn't my code nor layout causing the problem, it was the admob AdView using the loadAdOnCreate="true" to create ads. It's bitter, because I now may have to switch sources of revenue if I can't remove the loading delay created by the AdView! That was a tough one to find, I should have anticipated this though!
I am developing a pathfinding algorithm for an Android game, and I can write a recursive version (which is nice, but needs a big stack, so I might need to create a dedicated Thread for this with bigger stacksize), and a "loop" version which uses a buffer (instead of recursion). It is also a big problem that I don't know the size of the buffer in advance, so currently only the stack-based solution looks feasible.
I know this may be an algorithm theory or general computer science question, but perhaps it's Android specific because the stack size is a system-specific feature after all.
Generally, which should be more efficient (speed) on Android? The stack one, or the one which relies on buffer (heap)? Note that the question approaches the problem architecture-wise (assuming that the algorithmic complexity doesn't depend whether the algorithm is recursive or loop-based).
I know you asked for a Android specific answer, but I don't think it's really relevant to your problem. Two remarks
You don't necessarily need a stack based solution to implement a
recursive algorithm, you can emulate the stack on the heap with a
stack based data structure. Some times you don't even need this, though. This takes a bit more work, but don't base your algorithm on artifical architectural constraints.
There are plenty of non-recursive pathfinding, shortest path algorithms, ie Bellman-Ford
I can't comment on whether the most optimal recursive solution to a problem is going to be better than the most optimal iterative solution on Android. Usually, all other things being equal, the iterative solution is going to be faster, but when you get to more complex algorithms than say, Fibonacci numbers, implementing an iterative algorithm recursively or vice-versa might make a difference.
My gut feeling is you're about to commit the sin of early optimization. Do you have any calculations or measurements that indicate you'll run out of RAM?
I recommend that you use the simplest algorithm you can. You may however want to use AsyncTask so as not to freeze the UI, even for a second.
Is there any downside to making every one of your methods synchronized in Android?
Yes - it will end up taking out locks when you don't really want them. It won't give you thread safety for free - it'll just slow down your code and make it more likely that you'll run into deadlocks due to taking out too many locks.
You need to think about thread safety and synchronization explicitly. I usually make most classes not thread-safe, and try to limit the number of places where I think about threading.
The "make everything synchronized" approach is a common one in what I think of as the four stages of threading awareness for developers:
Complete ignorance: no synchronization, no awareness of the potential problems
Some awareness, but a belief that universal synchronization cures all ills
The painful stage of knowing where there are problems, and taking a lot of care over getting things right
The mythical stage of getting everything right naturally
Most experienced developers are in stage 3 as far as I can tell - with different levels of ease within it, of course. Using immutability, higher-level abstractions instead of the low-level primitives etc helps a lot - but ultimately you're likely to have to think a fair amount whenever you've got multiple threads which need to share state.
I've been reading a lot of posts and articles extolling the speed of Parcelable over Serializable. I've been using both for a while to pass data between Activities through Intents, and have yet to notice any speed difference when switching between the two. The typical amount of data I have to transfer is 5 to 15 nested objects with 2 to 5 fields each.
Since I have about 30 classes which must be transferable, implementing Parcelable requires a lot of boilerplate code that adds maintenance time. One of my current requirements is also that the compiled code should be as small as possible; I expect that I could spare some space by using Serializable over Parcelable.
Should I use Parcelable or is there no reason to use it over Serializable for such small amounts of data? Or is there another reason why I shouldn't use Serializable?
For in-memory use, Parcelable is far, far better than Serializable. I strongly recommend not using Serializable.
You can't use Parcelable for data that will be stored on disk (because it doesn't have good guarantees about data consistency when things change), however Serializable is slow enough that I would strongly urge not using it there either. You are better off writing the data yourself.
Also, one of the performance issues with Serializable is that it ends to spin through lots of temporary objects, causing lots of GC activity in your app. It's pretty heinous. :}
Continue to use Serialization. You'll see lots of people online who will tell you that Serialization is very slow and inefficient. That is correct. But, one thing you never want to do as a computer programmer is take any comment about performance as an absolute.
Ask yourself if serialization is slowing your program down. Do you notice when it goes from activity to activity? Do you notice when it saves/loads? If not, it's fine. You won't get a smaller footprint when you go to a lot of manual serialization code, so there is no advantage there. So what if it is 100 times slower than an alternative if 100 times slower means 10ms instead of 0.1ms? You're not going to see either, so who cares? And, why would anyone invest massive effort into writing manual serialization for 30 classes when it won't make any perceptible difference in performance?
Everybody just blindly states that Parcelable is better and faster, than Serializable, but nobody has tried to support his statements with any proofs. I decided to test this myself and I got very interesting results.
Usual Java serialization on an average Android device (if done right) is about 3.6 times faster than Parcelable for writes and about 1.6 times faster for reads.
You can check my test project here: https://github.com/afrish/androidserializationtest
Has anyone considered serialization using JSON and passing the data as a string? GSON and Jackson should be efficient enough to be a competitor to Parcelable as well as Serializable.
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 and 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.