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.
Related
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
I have build a pinball game in unity 3d for android and for some low mobile devices it is running slowly. I was thinking about hiring a unity expert to lighten up the code so it would run better on all devices.
But I wonder if this is possible. Can you make a game preform better by changing the code? I have to add this was my first unity project and it's very messy.
Thanks for helping
Absolutely, there are plenty of ways that changes to code could yield significant increases in performance, depending on how you're currently doing things.
One of them is object pooling when dealing with frequent creation/destruction of objects, another is caching component references when they are used often every frame. And if you're still using OnGui for your interface, probably avoid it in favour of the new (as of 4.6) GUI system. But you haven't included your code in your question, so I can't give a definite solution for optimizing your code.
Chances are though, not all of your code is problematic, just key scripts. My suggestion is to take a look at the Unity Profiler to determine which areas in your code are slowing down your game the most, then take steps to try reducing the execution time. You should also take into consideration non-code problems (eg. With lighting, geometry, materials, textures). Take a look at the guide Unity provides for ideas on how to address those
If you're still having problems, then you can bring that specific code to StackOverflow and see if it can be further improved. Hope this helps! Let me know if you have any questions.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
Is it really important to know algorithms to build mobile applications? I have strong understanding of development tools and design pattern as well as strong knowledge of OOP and MVC.
So, is it required to know hardcore algorithms to become a good mobile application developer?
I can understand that if you want to create games then YES it is obvious that we must know all the AI related algos to be competent. But I am asking for just simple data driven application building.
Every computer program you write implements an algorithm or a set of algorithms. If you are concerned with the quality (deliberately vague term) of your programs then you have to be concerned with the quality of your algorithms.
For example, if you want your program to be fast (which is a quality that a program might have) better choose a fast algorithm than a slow algorithm for the same problem. If you want your program to fit into a small amount of RAM (another quality factor) best choose an algorithm which operates in a small amount of RAM rather than one which gobbles it up by the GB.
So, critical knowledge for a software developer includes the knowledge of how to analyse an algorithm for speed, memory usage, and all the other quality factors you might be interested in optimising. One way of analysing an algorithm is, of course, referring to texts which tell you what you want to know.
I conclude with the assertion that yes you do need to know hardcore algorithms to be a good developer, I don't see any reason to modify my belief when it comes to mobile applications development. Of course, I don't expect you to know all about all the algorithms there might be, but the principal ones found in all the basic text books, and the ones which are specific to your application domain, hell yes you gotta know those rascals !
I think it's irrelevant being for the mobile area or not. You should always try to achieve the best possible solution (there aren't perfect ones). In the mobile area, particulary, performance is very important, because we are talking about small devices, that although in recent years have been getting a major hardware boost, you should always take special care. I always use memory leaks to check if something is wrong with what I do. I also check the heap memory to see if there is something consuming too much memory. Battery is also a concern and you should also test if your application is using too much.
At the moment I am really focusing on the architecture of the application, a working application in the current standards (at least on my owns) is not enough. Knowing patterns is a powerful tool, and you should read about those (one of the best is this one). Maintenance's costs are a major factor these days, and you should try to achieve the maximum code reusability and cleanness. Always assume that the client will change spec and always keep in mind that someone else in the future will maintain your code, so avoid long methods and over complex code (unless you have to do it). Also remember to leave comments, even if something is really simple, be humble... In a month you might not now what that "simple" stuff did. Those things are fairly easy to achieve when you are starting a project from scratch but a pain when you need to start thinking about those when the project is going to production in one week..
So as for your question: is it required to know hardcore algorithms to become a good mobile application developer?
My answer is: No, it helps, but there are others important parts when developing, besides algorithms.
Good algorithms can have a direct impact on battery consumption for your phone as well as how much of a memory footprint it has. Every developer should strive to use the best algorithm possible, but that doesn't mean it is absolutely necessary.
The smaller and more resource constrained your platform the more important it is to know algorithms. So on mobile it would be even more important.
i have an application which has a part where some variables are written and read at very high frequency.
Is there any need of a semaphores or locks(Data consistency is not a concern in this case).Is there any chance of application terminating or crashing.I dont want to get into threads,semaphores and stuff as it is a trivial part of application.
There is not nearly enough information in your question to give you an accurate answer, but in general - if you have multiple threads, and one produces data, one consumes it, then yes, you will need synchronization.
You could use a BlockingQueue, or just a simple synchronized object, whatever is appropriate in your case... but you will need some synchronization, or else you risk random hard-to-reproduce crashes.
This is even more important when dealing with multi-core systems, which are becoming popular now.
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.