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

CORRECTION: optimizing with === immutable comparitor

Thread Previous | Thread Next
Darren Duncan
July 14, 2006 01:12
CORRECTION: optimizing with === immutable comparitor
Message ID:
At 12:30 AM -0700 7/14/06, Darren Duncan wrote:
>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 

Sorry, I stated some things badly in that previous email, mainly the 
"$a := $b" part, which is technically incorrect, so I will try and 
clarify what I meant to say.

What I propose concerning non-premature === optimizing is a system 
where, at any time that two appearances of the same immutable value 
are compared with ===, they are immediately consolidated into a 
single appearance.  Or at least $a.value := $b.value occurs 
immediately, and garbage collection of the second and now 
unreferenced copy happens whenever it would happen.

For illustration:

  $a = 'hello'; # one copy of the value 'hello' in memory
  $b = 'hello'; # a second copy of the value 'hello' elsewhere in memory
  $c = 'world'; # one copy of 'world' in memory
  $a === $b; # now only one copy of 'hello' is in memory, $a and $b point to
  $a === $c; # nothing changes, as values are different
  $b = $c; # now only $a points to 'hello', $b and $c point to one 'world'

I of course did not mean for the actual symbol $a := $b to happen, 
only what they point to internally.

Of course, the above example could be constant folded to one copy of 
'hello' at compile time, but my illustration is meant to be for 
situations where $a and $b are declared or set far apart, possibly 
from run-time input values, so the folding happens at run time.

What I meant with the =:= shortcut then, is that $a.value =:= 
$b.value could return true following the above run of $a === $b.

Sorry for any confusion.

FYI, I plan to explicitly illustrate the principle in my next 
Set::Relation update, since its types are immutable, so that any 
operations which involve comparing two relations or tuples or 
headings or values therein with === will have a side-effect of 
consolidating them if they are equal.  Later on, if this happens at 
the language level, I would less likely have to do it myself.

-- Darren Duncan

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