On Apr 17, 2006, at 1:34, Chip Salzenberg wrote:
But: I see extensive use of PMC_(struct|pmc|int|num|str)_val() in
*.pmc.
Sure. There are just these 1 or 2 data items in the PMC and these are
of course heavily used. But e.g. a Resizable<x>Array would need 3
items: n_first_elem, n_elements, and n_allocated.
The Complex or BigInt PMCs don't have enough space to store their data,
so these use a malloced storage hanging off PMC_struct_val...
OTOH a plain Integer just needs one data item...
So triple indirection is hardly universal. Granted it is necessary
for
some cases, but the situation isn't as unliveable as I understood
you to
say earlier.
+ BTW, I don't see any use of PObj_buf(start|len) in *.pmc, and I
find
this odd. Surely there must be PMCs that would find it helpful
to
have both a pointer and a length without additional
indirections...?
PObj_buf{start,len} is used by bufferlike PObjs e.g. STRING* or for the
storage of array PMCs derived from list.c (Array, PerlArray). The
buffer may move during GC (src/resources.c:compact_pool()), which is
sometimes not really wanted.
* A consequence of variable-length PMCs would be a merging of PMC_EXT
into
PMC.
Yes, at least for these parts that are really needed. A PMC that
doesn't contain any other PMC doesn't need C<_next_for_GC> (this item
is used for DOD mainly, to avoid deep recursion). C<_metadata> - the
property hash - shouldn't be needed in the long run: a perl6ish '0 but
true' creates a new Role according to S12.
Why wait for variable-length PMCs to get rid of PMC_EXT? Doing so
now
would eliminate an indirection and a pointer, which should help
according
to your theory.
Just appending PMC_EXT to the PMC slows down Integer and Float. These 2
PMCs don't need anything from PMC_EXT. OTOH a Complex or BigInt PMC
would still need the malloced storage for it's data.
I'm told that PMC_EXT was introduced to help cache line behavior,
No. It was introduced to reduce PMC size for Integer and Float. The
size reduction of scalar PMCs reduced data cache misses.
leo
