Re: What's up with token filters (Re: New operators?)

[Rici Lake <lua@...>]

Asko Kauppi wrote:
> Can you give practical examples about cases, where Lua code could be 
> optimized?

The most important optimization is constant folding and dead-code
elimination.

Lua currently does constant folding, but only for
literal numeric constants (and not for constant comparisons in
if statements).

However, a two-pass compiler could identify locals which are
constant, and propagate this information into the constant
folding stage. That can produce significant speedups.

Another useful optimization would be function call inlining.
If the compiler can prove that a particular closure is
constant, then it can inline the function call, which produces
a dramatic speedup.


> I tend to think that compiler optimizations are way more important in 
> C(++) than in something as high level as Lua. Or, put another way, if 
> one does sloppy (slow) Lua coding, the compiler wouldn't be smart enough 
> to "do it right" on your behalf, either.
>
> I.e. replacing a number of a= a..b with table.concat() is way outside of 
> the optimization scope, right?

That could be done, although it's probably better to write the code
correctly in the first place. :) However, it would theoretically be
possible to handle this in an optimization step:

local a = "prefix"
if some_condition() then
  a = a .. " middle"
else
  a = a .. " other middle"
end
a = a .. " suffix"

It would be tricky and I don't know that that occurs often to warrant
it. Also, you could just write:

local a = "prefix"
          .. some_condition() and " middle" or " other middle"
          .. " suffix"


> -asko