Tels <[EMAIL PROTECTED]> writes:
>> At first I thought this was due to size-considerations. However,
>
>That was the idea. I thought that a SV always has a IV, NV and PV slot, so
It doesn't. See Gisle's diagrams.
SV * has ONE pointer to a separately allocated "something".
The least memory case for an XS object is the SvPV one with a C
struct "hidden" as binary data in the "string".
This saves one C level indirection in speed, and one.
>Bigint is:
>
> 4 (int on my system)
> 8 (double on my system)
> 4 (ptr on my system)
Hmm. Probably makes sense to order that
so two 4-bit things are adjacent.
>
>That makes 16 bytes. If I malloc this, it probably needs 16 bytes (malloc
>might padd!), and storing an PTR in the IV of the SV needs:
On a 32-bit machine...
The fixed part of overhead for an Object in perl is:
The SV * for the reference needs 3 words.
The XRV * of that reference SV needs 1 word.
The SV * for the object needs 3 words.
Then you have the representation cost.
An SvIV costs one word for IV slot
+ malloced struct costs N words+sysmalloc overhead
vs
An SvPV costs 3 words (ptr,cur,len),
+ N words + perlmalloc overhead.
So the PV costs two more words in the trivial case, but saves
one level of indirection on access.
Note that all perl's odd-sized structs are allocated in chunks.
So that we get (say) 1000 1-word XRV * from perlmalloc,
and then hand them out on newRV() to SVs till we run out.
In another place we got say (say) 330 3-word XPVs from malloc
and hand those on newPV()
>
>38 bytes, so the malloc() strategy would actually be less (IIAC). Why is the
>SV bigger? CUR/LEN overhead?
As soon a you print (or otherwise stringify) a numeric
it goes from being a bare NV or IV to PVIV and gains a allocated
string for the stringified thing.
>
>Actually, I am not sure whether Devel::Size is even correct:
Perl code that gropes internals runs the risk of disturbing the state.
Bit like quantum mechanics...
>
> # perl -MDevel::Peek -le '$a = "8"; $b = 8; $a = 8; $a += 0.9; $b = 9;
> print Dump($a),Dump($b)'
>
>Anyway it really seems the malloc()/free() strategy might take less memory.
Maybe (I am skeptical), but if you malloc it is in SvIV
and you get an extra indirection.
I have found over the last 9 years or so that puting data in PV
is reasonable way to go. Tk does this for small structs,
and Audio::Data does this for large arrays of 'float'. Seems to
work well enough in both cases.
>
>> But when using all three slots in a clever way it has the advantage that
>> at least the IV slot can be accessed from a Perl script, namely in
>> numeric context.
But beware perl thinking it knows what it is doing in such cases.
It will only use the IV slot if SvIOK is set, but if it isn't and
there is an SvPOK set then it will do perl's conversion
of string to IV and overwite your IV. Possibly worse if you say
it has IV and it wants a string it is likely to convert IV to string
and write it over the SvPV slot.
>
>I wouldn't allow this, though :)
Good.
