Lua is kind of laggy. Lol.

[zac352]

If you've played my most recent project, you know that having 1000+ food is murderous to your processor.

[kikito]

Speed and ease of reading are not opposed. They go together more often than they work against each other.

Altough it is possible that lua is slowing down your program, the chances are that there is some bottleneck on it.

Trouble is, it is difficult to find bottlenecks if the code isn't easy to read.

[zac352]

Speed and ease of reading are not opposed. They go together more often than they work against each other.

Altough it is possible that lua is slowing down your program, the chances are that there is some bottleneck on it.

Trouble is, it is difficult to find bottlenecks if the code isn't easy to read.

My code isn't very easy to read. But I'm pretty sure iterating through a thousand objects one hundred times performing several mathematical operations is bad on your processor. :p

[vrld]

Kikito is right. Well written code tends to be both readable and fast.
In addition to that, the Lua interpreter is really fast. I doubt the interpreter is a big bottleneck in most cases.
Using better data structures and algorithms yield the highest speed gains and should always be the first step when trying to optimize (the 0th step being to use a profiler) ones code.
Micro-optimization on the other hand tend to be very frustrating while only giving little boosts...

Edit:
Having a quick look on your code, I think you could improve it by reviewing the nearest neighbor search...

[Robin]

Using better data structures and algorithms yield the highest speed gains and should always be the first step when trying to optimize (the 0th step being to use a profiler) ones code.

Shouldn't you think about which algorithms you use even before you start implementing them?

[vrld]

Shouldn't you think about which algorithms you use even before you start implementing them?

Yes and no. Of course you have to identify the type of problem (e.g. 'find the closest point'), but the mechanism to do that can vary. Take the nearest neighbor problem:
The obvious ("naive") method is to take the distance to every other point and then take the one which is closest. If you have n potential nearest points, you will have to calculate the distance to all these n points, so the big-O runtime of this algorithm is O(n).
A less obvious method is to organize the points in a special search structure where you can instantly say that some points will have a larger distance to the test point than a special one. Thus you can reduce the runtime of the search. Of course you will have to create the structure first, which will take time itself, but if you test for nearest neighbors way more often than you have to update the structure, this will still decrease the overall runtime.
Another less obvious search structure is a grid that overlays all points. If you want to know the distance to a test point, you will calculate which cell this point would occupy and then look for nearest neighbors in this and surrounding cells, thus avoiding a lot of calculations which had to be done using the the naive algorithm.

It is perfectly OK to implement the naive solution first, because it is in most cases also the easiest one, but if the program gets slow, and the profiler tells you that your algorithm for nearest neighbor search is to blame, then you might want to consider solving the problem with a different method.

[zac352]

Kikito is right. Well written code tends to be both readable and fast.
In addition to that, the Lua interpreter is really fast. I doubt the interpreter is a big bottleneck in most cases.
Using better data structures and algorithms yield the highest speed gains and should always be the first step when trying to optimize (the 0th step being to use a profiler) ones code.
Micro-optimization on the other hand tend to be very frustrating while only giving little boosts...

Edit:
Having a quick look on your code, I think you could improve it by reviewing the nearest neighbor search...

It was only a test to see if prioritising everything would succeed in making a cell that won't die of starvation because it doesn't feel like eating.

[zac352]

Shouldn't you think about which algorithms you use even before you start implementing them?

Yes and no. Of course you have to identify the type of problem (e.g. 'find the closest point'), but the mechanism to do that can vary. Take the nearest neighbor problem:
The obvious ("naive") method is to take the distance to every other point and then take the one which is closest. If you have n potential nearest points, you will have to calculate the distance to all these n points, so the big-O runtime of this algorithm is O(n).
A less obvious method is to organize the points in a special search structure where you can instantly say that some points will have a larger distance to the test point than a special one. Thus you can reduce the runtime of the search. Of course you will have to create the structure first, which will take time itself, but if you test for nearest neighbors way more often than you have to update the structure, this will still decrease the overall runtime.
Another less obvious search structure is a grid that overlays all points. If you want to know the distance to a test point, you will calculate which cell this point would occupy and then look for nearest neighbors in this and surrounding cells, thus avoiding a lot of calculations which had to be done using the the naive algorithm.

It is perfectly OK to implement the naive solution first, because it is in most cases also the easiest one, but if the program gets slow, and the profiler tells you that your algorithm for nearest neighbor search is to blame, then you might want to consider solving the problem with a different method.

I can't really see anything I could do with it. Ever since I implemented sunlight, plants stay around 30. I can't get any cells to mutate into carnivors to eat the dead ones, though.

[Taehl]

My code isn't very easy to read. But I'm pretty sure iterating through a thousand objects one hundred times performing several mathematical operations is bad on your processor. :p

The average processor today is about 2 gigs. That means they can do over two /trillion/ calculations per second. It's not the iteration and the math that's slowing you down (Lua is very efficient at both), but, as others have said, your nearest-neighbor implementation, which needs a better algorithm.

If I were you, I would see if I could do something fancy with tables which would negate the need for actually searching.