Front page | perl.perl5.porters |
Postings from November 2014
On the sprout/pn branch, I have created a pad name struct:
struct padname {
char * xpadn_pv;
HV * xpadn_ourstash;
union {
HV * xpadn_typestash;
CV * xpadn_protocv;
} xpadn_type_u;
U32 xpadn_low;
U32 xpadn_high;
U32 xpadn_refcnt;
int xpadn_gen;
U8 xpadn_len;
U8 xpadn_flags;
};
which is 5.25 pointers large on 64-bit platforms.
And, to allocate a string buffer as part of the same chunk of memory:
struct padname_with_str {
struct padname xpadn_padname;
char xpadn_str[1];
};
Now this allocates the 'padname_with_str' with six empty octets before
the string. So for short pad names we use 7 pointers.
I could fiddle things a bit to get the string buffer to begin at
xpadn_flags+1. That would get us down to 6 pointers for four-char
names like $self, or even 5 (or 6 for longer names) if we can merge
typestash and ourstash, as I suggested in another thread ('our
Type $thing').
A couple of years ago someone pointed out that memcmp is faster at
pointer-aligned addresses. But how much faster? Is it noticeable?
Note that this would only happen during pad name lookup at com-
pile time.
If I count them correctly, we currently have 3 + 2 + 4 (sv head +
string + xpvnv) = 9 pointers allocated for most pad names, and 11 for
our/typed/mysub pad names. So either way I am still saving memory.
But I need advice on the best way to proceed.
The two pointers for the string buffer are shown by LEN = 10 below.
$ ./perl -Ilib -e 'use B; use Devel::Peek; Dump B::svref_2object(sub {my$self})->PADLIST->ARRAYelt(0)->ARRAYelt(1)->object_2svref'
SV = IV(0x7fff2c0780d0) at 0x7fff2c0780e0
REFCNT = 1
FLAGS = (TEMP,ROK)
RV = 0x7fff2c02feb8
SV = PVNV(0x7fff2c06c728) at 0x7fff2c02feb8
REFCNT = 2
FLAGS = (POK,pPOK)
IV = 0
NV = 6.83282644849413e-312
PV = 0x7fff2bc21d78 "$self"\0
CUR = 5
LEN = 10
Thread Next