develooper Front page | perl.perl6.language | Postings from July 2006

Re: optimizing with === immutable comparitor

Thread Previous
July 14, 2006 00:58
Re: optimizing with === immutable comparitor
Message ID:
On Friday 14 July 2006 00:30, Darren Duncan wrote:

> This may go without saying, but ...
> If $a === $b means what I think it does, then I believe that a
> not-premature implementation optimization of === would be that it
> always $a := $b if it was returning true, so that any future === of
> $a and $b or aliases thereof could short-circuit with a =:= test even
> if they weren't created as aliases, and Perl would be automatically
> more memory efficient without those extra storage copies.
> I know that was an implementation issue, but I think that it stands
> to be explicitly stated anyway, as it is a very simple and effective
> way to make Perl programs more resource efficient, possibly by orders
> of magnitude, over not doing so.

First there was copy-on-write and now there's share-on-compare?

> (The only time this may not work is if so-called immutable types are
> tied to external resourses, but then I'm not sure how often this
> would happen in practice so it could just be an exception if
> necessary.  The above-stated rule would still stand for any resources
> managed by Perl itself.)

In the absence of much Perl 6 code either way, I wonder at the value of adding 
such an extreme side effect to a simple comparison operation.  This goes way 
beyond loop hoisting and constant folding.

I can understand singleton value types (even Perl 5 does that with PL_undef), 
but ... wow, you have a lot more faith in local code analysis than I do.

-- c

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About