Tables vs closures for representing objects (and JITability)

[Matthew Wild <mwild1@...>]

Hi all,

I've come into a little debate recently. We're working on an API,
which will be used to create *lots* of small objects. Performance is
critical above everything else (don't shout at me for this :) ).

The debate is whether to represent objects the standard way - as
tables of methods (the methods being closures for efficiency), or as
just a single closure each, that takes the method name as its first
parameter, and has if/elseif. We're looking at about a dozen fixed
methods max per object.

The latter seems like it would win out, and produce less garbage, etc.
The downsides are obvious - it isn't possible (well, easily) to add
properties to the object dynamically- so I don't want to do it
needlessly. Is this the only thing I'm trading for speed?

One of the main things I'm also interested in is which approach would
be most JIT-friendly. The latter representation of objects is
uncommon, so I'm concerned LuaJIT may already be optimised for
tables-as-objects, and I'll be wasting my time.

In anticipation of replies... the argument that any gain wouldn't be
noticeable and therefore isn't worth it doesn't really hold out...
*everything* becomes noticeable once you multiply by a large number :)

Thoughts?

Matthew