Re: ffi.new vs ffi.C.malloc speed
- From: Mike Pall <mike-1210@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 10 Oct 2012 17:37:47 +0200
Ronan Collobert wrote:
> Sometimes we need large vectors (which in general have a long
> lifetime), sometimes we need to allocate/deallocate a lot of
> small vectors.
>
> If I want something general, I need to use malloc instead of
> ffi.new (because of the possibility of large vectors) -- in that
> respect, the benchmark is really meaningful (and I checked this
> behavior in practice).
If this is from the same code path, you could simply allocate the
smaller ones with ffi.new() and the others with malloc. From the
users point of view the resulting objects behave the same.
> > Finalizers will become cheaper, but their overhead is still
> > substantial.
>
> Ok. I assumed ffi.new() relies also on some kind of finalizer,
> so I am not sure to understand why the ffi.gc way would be
> slower, even if it was compiled... I suppose I would have to
> read luajit code to get it ;)
Calling a finalizers means setting up a frame etc. and calling
into the VM to run the finalizer. That's costly. Sure, I can
imagine a shortcut if the finalizer is a FFI C function (on my
TODO list for 2.1), but it won't be free either.
Also, the GC for LuaJIT 2.0 and 2.1 handle allocated objects very
differently. There's no explicit 'free' call anymore with the new
GC, which makes deallocation very cheap (sweep phase). For objects
with finalizers one has to manage an explicit list. And traverse
the list and check the objects at strategic points, too. None of
that overhead is necessary for objects without finalizers.
--Mike
Other related posts:
