On 12/04/2013 02:22, Marvin Humphrey wrote:
On Thu, Apr 11, 2013 at 5:38 AM, Nick Wellnhofer <[email protected]> wrote:
Currently, we lazily allocate a Perl object when the refcount exceeds 4 even
if we don't really need it. There's a common technique to store flags in the
least significant bits of an aligned pointer that could be employed here.
Assuming that SVs are always allocated on even memory addresses, we could
use the LSB of the lucy_ref_t union to signify whether the value is a
refcount or a pointer to a host object. So we'd have all the other bits to
store refcounts, and we'd only have to allocate a Perl object if we really
need it.
+1, this would be a nice improvement.
OK, I started to implement this optimization and I noticed that there
are some places where refcounts are initialized in the 'core' code. I
think we should either use VTable#Init_Obj instead or move these
functions to the host language code. My plan is to move VTable#Make_Obj
and VTable#Init_Obj and convert the rest to use VTable#Init_Obj.
If we allocate a Perl object then, I'd create the RV pointing to the inner
object right away, store it in host_obj, and use it for refcounting. This
saves a bit of memory and cycles if a Clownfish object is converted to a
Perl object multiple times. Then we could also use sv_bless directly which
is a bit slower than the code in S_lazy_init_host_obj but more
forward-compatible (PL_sv_objcount will be deprecated in Perl 5.18, for
example).
So let me see if I understand correctly. If we store that RV, can we incref
it and pass it into Perl-space an arbitrary number of times? If so, then it
seems worthwhile to accept the extra RAM cost of caching the RV in addition to
the inner object SV.
For some reason, I initially thought this could save RAM. But you're
right, it's actually a memory/speed trade-off. I think it should work,
but now I'm not sure whether it's worth the additional memory cost.
Nick
