5

I am a beginner and have currently started working on a game for Android which uses a particle swarm optimization algorithm. I am now trying to optimize my code a little and i have quite a lot of Math.random() in for-loops which is running almost all the time. So i was thinking of a way to get around and skip all the Math.random() calls.

By using a method like this:

    float random[] = new float[100];
static int randomIndex=0;

private float myRandom(){
    if(randomIndex >= 99)
        randomIndex = 0;
    else
        randomIndex = randomIndex+1;
    return random[randomIndex];
}

...and also do this one time when the activity starts:

for (int i=0; i< 100; i++)
        random[i]=(float) Math.random();

My question is if this will be better (faster) than using Math.random()? Does anyone have a better suggestion how to do?

I also wonder if anyone know any good site where i can read more about how to write efficient java/android code. I'm afraid i kind of suck on it.

Weldeborn
  • 114
  • 1
  • 8

3 Answers3

6

Learn to trust the Java API: it's powerful and fast. "Premature optimization is the root of all evil." Make your program work before you start worrying about things such as this.

For your purpose however it might set your mind at ease to compare your method vs. Java's in a loop of say 30 million, then compare the times.

Not to mention filling an array of 100 random numbers then using it a million times is not random at all.

duffymo
  • 305,152
  • 44
  • 369
  • 561
Gunnar Hoffman
  • 1,226
  • 1
  • 11
  • 11
  • Okay, so I've build an app that heavily relies on math.Random and it is slower than I wanted it to be (it is a load testing tool that generates a huge amount of random events). I've profiled it and found out that most of the time it spends around random part. Then what? – om-nom-nom Jun 29 '13 at 10:21
  • 2
    @om-nom-nom why don't you move the random creation to another thread, you can use a blocking queue to build a producer/consumer relationship offloading or even preloading random numbers. – Gunnar Hoffman Jun 29 '13 at 14:21
3

That will certainly be faster, but it will not be "better" in the sense that it will not generate very good random numbers. Maybe that's OK for your game; maybe it's not.

There are a few drop-in implementations of java.util.Random that are likely to be fast. You could check out the Uncommons Maths library but there are bound to be others out there too. Uncommons has the "XORShiftRNG" which is designed to be fast.

Be careful to not do any premature optimization: if Math.random is fast enough in practice then don't bother finding a replacement. Make this decision only after doing some analysis of the actual time spent in that section of the code.

Cameron Skinner
  • 51,692
  • 2
  • 65
  • 86
1

Here is an article on optimization http://www.javaworld.com/javaworld/jw-04-1997/jw-04-optimize.html?page=1

What you are talking about is making a lookup table for your random numbers. Most of the time this is faster but in this case it will also change the results.

In general my approach is always find the thing that is taking the most time, and investigate it as deeply as I can. Make sure you are not doing redundant work, and look for things that seem oddly slow. Optimized code tends to spend most of it's time on basic math operations. Try to keep going until it looks like you spend most of your time on just the math ops.

Your code is doing something, and there may very well be a better way to do that. So keep an ear to the ground for the best algorithm.

And keep in mind, there are all kinds of android devices out there. It will be hard to optimize for all of them. Sometimes you have to take a solid pass at optimization and then assume that's as good as it's going to get and start reducing the amount of work happening or decide it's just not possible.

madmik3
  • 6,975
  • 3
  • 38
  • 60