Re: OO call vs normal call

[Mike Pall <mikelu-0705@...>]

Hi,

Mark Hamburg wrote:
> > - 100-200 ns for a closure or table allocation plus collection
> 
> My guess based on other profiling that I've done, is that memory allocation
> and deallocation is the killer here though creating more work for the
> garbage collector is probably also a problem.

The slowness is mainly because of excessive layering (4 call
frames between luaV_execute and realloc) and because calling
realloc/free for every 32 byte table object is very inefficient.

Bulk allocation and a simple sweeping allocator can bring the
table creation overhead down to a post-increment of a pointer.
Garbage collection gets trickier because you may need to move
objects for optimal compaction. But the literature has many
solutons to offer for this problem (forward objects, reference
replacing GC and so on). I think one could reduce the alloc/GC
overhead by a factor of 10x with a good design.

> What I've been thinking might be useful is some form of simple escape
> analysis -- possibly purely runtime -- that would detect values that don't
> develop roots outside the stack in which they are allocated and collect
> those more rapidly. This could then be coupled with maintaining a free list
> at the Lua universe level which would be able to bypass any thread safety
> protections in malloc and free.

INTRAprocedural escape analysis is not so difficult, even though
it requires data-flow analysis. But it's rather pointless because
it doesn't cover the interesting cases. Alas, INTERprocedural
escape analysis is known to be very difficult. The rich dynamic
semantics of Lua don't make this any easier ...

Bye,
     Mike