[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Tables vs closures for representing objects (and JITability)
- From: Matthew Wild <mwild1@...>
- Date: Thu, 12 Nov 2009 15:36:54 +0000
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 :)