David Robins wrote:
On Thu, 19 Dec 2002, Leopold Toetsch wrote:
Well, what I was getting at was that if dest is, say, a RomanNumeralInteger whose value is "mcmlxxxiv", I don't want it to waste time converting that to the integer 1984 when I morph it to a PerlInt, if my next step is to unilaterally set its value to 5.
No need to look at *dest, just tell it to convert itself to a PerlInt with value 5.
Currently we are "morphing" perlscalars all over the place. We do this by replacing the vtable (and in case of strings) also changing flags.
Which is sort of evil, but it makes up for that by being fast, I guess :D.
Yes, and might need changes in the future.
This discussion might yield more specific results, if Dan /* hallo - cc'ed */ could tell us, what the usage of morph really is.
Cloning or making a new PMC for each LHS isn't that cheap. I think we should reuse existing headers where possible. The same holds for string headers, which are currently sparely reused.
One would hope it could be made as cheap as Perl's SV allocation, which with the plant/uproot mechanism, is probably pretty darn fast. Even allocating memory isn't bad if it uses the fixed-size allocator.
Normally PMC's are returned from the free list, but when each assignment does make a new header, you would spend a lot of time in DOD/GC. (reusing a string header for substr gave IIRC +50% speed improvement in life.pasm)
Still, with the present "dest* PMC", how is a new PMC to be returned? Since
the address is the same, the old one won't be GC'd, thus destroy won't be
called (so it will need to be called explicitly as I had in an earlier
message). Then the new vtable/flags have to be set and init called
Yep, that is - thinks /me - what should be hidden inside morph.
Dave
leo
