Re: Lua Pre-compiler / Lua side userdata

[Chris Gagnon <cgagnon@...>]

> Can't you create a table of events? Your example would become
>
> PostEvent(Events.ButtonClick)

An event is but one example of the uses of hashed strings in the project, and they can be arbitrary named by the script writers.
Maintaining a table of events like:
PostEvent(Events.ButtonClick)
would likely be a pain.

This creates a C++ code dependency which lowers the usefulness of scripting (fast iteration on changes).
Otherwise it's all done lua side which still runs into the hash precision issue.

> Have you actually benchmarked this?  The string will be folded into the
> constants table at compile time, and should take a similar amount of
> time to load from it as a numerical constant.  Additionally, string
> comparison for equality boils down to a single pointer compare, so is
> very quick; not to mention more readable.
>
> B.

I have not bench marked this, the problem is internal systems still require the hash so the calculation of the hash is an overhead I'd like to avoid.

More thoughts?

-Chris

On Mon, Oct 12, 2009 at 1:09 PM, Andre de Leiradella <aleirade@sct.microlink.com.br> wrote:

Can't you create a table of events? Your example would become

PostEvent(Events.ButtonClick)

You can assign numbers to entries in the Events table so Events.ButtonClick will translate to an number (one that fits in a float) which you can easily compare in the C side.

Cheers,

Andre

Chris Gagnon wrote:

I'm come to a situation, where to maintain readability for script writers but ensure fast code i want to parse lua code before it goes to the compiler.
The issue i foresee is that I'll essentially want to create user data in the Lua script.

So an example in Lua:
PostEvent("ButtonClick")
very readable, however strings...yuck

I want to create a hash of that string for speed:
PostEvent( 0xABC45678 )

All is good you might think, however the gotcha is that that we compile lua using a 32-bit float to represent numbers.
Internally that float will lose the precision and hence mess up the 32 bit constant.

Basically I'm looking for any suggestions, as i don't have any great ideas that don't add needless run time overhead.

Thanks,
Chris