Collision with CIRCLES?

[rhezalouis]

How does the outer code look like?

the outer code is available here

[RLC]"Regarding Time Measurement"

• If the local b ... part was inside the loop, it is logical it is slower: it gives something like GETGLOBAL, GETDOTTED, SETLOCAL, GETLOCAL, CALL in byte code rather than GETGLOBAL, GETDOTTED, CALL. There should be an improvement in performance if you move the local b = math.sqrt outside the loop.

I assume the localizations is happened inside the love.draw() so that it would also called every cycle, so I put it inside the loop to simulate it. But, If you're lucky, sometimes even when the localization is put into the loop, the data could yield a better time average... .

[*]I'm not sure about this, but the Lua compiler might optimize constant expressions like 2^0.5. Change it to x^0.5 (where x is defined earlier to be a local with value 2) to see if it changes the outcome.[/list]

Hell, things are getting more weird:

Code: Select all

local x = 2; local b = math.sqrt;[outside the loop]
a = math.sqrt(x)                >> t avg = 3359.2µs [control]
a = b(x)                        >> t avg = 3300.6µs [2%faster than control t]
local c = math.sqrt; a = c(x);  >> t avg = 1738.2µs [48%faster than control t]
a = x^0.5;                      >> t avg = 3906µs   [16%SLOWER than control t!]

[Robin]

Ah, well. Maybe you should let it rest. After all, premature optimization is the root of all evil.

Lua in general is very fast, but even in languages which are significantly slower optimization is usually not worth it.

[rhezalouis]

Ah, well. Maybe you should let it rest.

Hahaha, maybe you're right. It's getting late here. I should take a rest too.

After all, premature optimization is the root of all evil.

Eh ? I thought, in programming, optimization should be taken as a programming mindset (instead of being applied later on which usually causes total system redesign). I am afraid that small time-unefficiency could be piled into a huge impact on performance, which is really a pain-in-the-ass to be changed as they are scattered accross the programme.

Lua in general is very fast, but even in languages which are significantly slower optimization is usually not worth it.

All hail Lua!

[kikito]

Eh ? I thought, in programming, optimization should be taken as a programming mindset (instead of being applied later on which usually causes total system redesign). I am afraid that small time-unefficiency could be piled into a huge impact on performance, which is really a pain-in-the-ass to be changed as they are scattered accross the programme.

That is not entirely true. The rationale is the following:

Little optimizations here and there might make your code go maybe a 5% faster.

The "good" optimizations, however, are changes in your code that as a result make everything go 1000% faster, while doing the same functions.

These latter optimizations are usually paradigm shifts - your code is rearranged so it does the same thing, just in a completely new way. For example, using a QuadTree or the A* algorithm instead of brute force.

As a rule, in order to make these "paradigm shifts" your want your code to be as modular as possible and as understandable as possible.

However, the "little" optimizations tend to (in general) make code less intelligible and less modular. Small optimizations that don't break encapsulation and don't obscure the code are ok.

That's why I prefer doing something that works, first, and then optimize any parts that are slow ... after profiling. Then I concentrate on making the code modular and intelligible. And then, if I have time to gold-plate it (very rarely) I try to apply local optimizations that don't obscure the code or break encapsulation.

[rhezalouis]

Waa, thanks for the insight, Kikito.

These latter optimizations are usually paradigm shifts - your code is rearranged so it does the same thing, just in a completely new way. For example, using a QuadTree or the A* algorithm instead of brute force.

Ah, I mean, if the QuadTree (the optimization) is put into consideration since the design process, couldn't we skip the brute force code and efficiently start with the tree instead (because as you have mentioned, it's quite rare to have the time to alter the build to the gold-optimized-version)?

As a rule, in order to make these "paradigm shifts" your want your code to be as modular as possible and as understandable as possible.

However, the "little" optimizations tend to (in general) make code less intelligible and less modular. Small optimizations that don't break encapsulation and don't obscure the code are ok.

Wow, that's a nice rule. Sometimes I do forget to keep true to modularity (especially when I'm thinking too much about optimization). OK, I'll keep that in mind. Yes, sometimes it's really hard to choose between readability and speed because sometimes comments are not helpful enough to let us understand what does the code 'used to' means.