Jan Dubois wrote:
> >Perl 5 basically clones on every assignment. As it uses refcounting, it
> >knows it doesn't need to clone a string if its refcount=1 and it's marked
as
> >temporary, i.e., only a temporary that will go away anyway knows about
this
> >string, so it's guaranteed no other reference to it will exist.
>
> I did experiment with this idea just for fun some time ago:
>
>
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-07/msg00550.html
That's exactly what I was looking for.
You point out two disadvantages:
> - It steal 2 bits from the SvTYPE flags. Flags are a *very* scarce
> resource and shouldn't be used up unless there are very good reasons
> for it.
>
> - Using shared strings is not totally backward compatible: Extensions
> *must* check if a SV* is shared and naturalize it if it intends to
> change the contents. Note that I had to patch one occurrence of this
> in the bundled Data::Dumper. This could be improved *some* by adding
> XSUBPP for it, but wouldn't help in case the extension accesses SvPVX
> directly.
Considering Perl 6 will be built from scratch, I think these are not an
issue anymore, right?
Other consideration I see is the ``no more refcounts'', which would make it
hard to see if something is SHARED (it's shared if refcount > 1). This would
mean we have no way to find out if something is or isn't shared, so that
every modification would have to `naturalize' (or clone) the data, instead
of reusing it. Would this be a too big overhead?
Actually, I've thought of a scheme that would allow reusing data, but that
would require the opcodes telling the values they want them to reuse the
data explicitly. That would require more complexity on the implementation
and optimizers that can find this kind of situation on the source code. That
means:
1) I avoid it, if I can; or
2) I'll go for it, if it's a big win.
- Branden
