At 10:25 PM +0100 1/3/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
I'm not willing to go so radically to start, but I did have an
idea. I think part of the extra cost is just in cache
fluffiness--the sync info just isn't being used much. I don't think
that it, or the property info, will be used most of the time. We
could yank the metadata and sync fields out of the PMC itself and
put them in a separate segment of the PMC's arena, and replace them
with a single pointer to the PMC's particular section.
A little bit more radically:
- a PMC has a PObj and a vtable (= 16 byte)
- if a PMC needs data, metadata or synchronize then
cache.pmc_val points to the "Extra PMC data" (our current PMC )
containing this fields so we do nether resize, but have for
aggregates or PMCs with properties one more indirection.
- PerlStrings move from ->data to ->cache.string_val
As programs tend to have much more scalars then aggregates and
probably more scalars w/o properties then with, this would win a lot
of precious cache mem.
Fair enough, though there's something just so bizarre about having
the cached value be a required part, and the data the cache is
supposed to be based on optional... :)
It ultimately increases the size of a PMC by one pointer if we
preallocate all the property/sync pairs, but it makes the PMC
itself more dense and, if I'm calculating things right, makes it
fit on an 8-byte boundary better.
Not here: current PMC 32 byte, simple PMC 16 byte.
Hrm, did the math wrong. Need to go double-check that.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
