develooper Front page | perl.perl5.porters | Postings from October 2004

RE: optimization idea

Thread Previous | Thread Next
From:
Elizabeth Mattijsen
Date:
October 26, 2004 03:24
Subject:
RE: optimization idea
Message ID:
f06110400bda3d526bb5d@[192.168.56.3]
At 10:30 AM +0100 10/26/04, Orton, Yves wrote:
>Dave Mitchell wrote at 25 October 2004 22:38:
>>  On Mon, Oct 25, 2004 at 09:09:16PM +0200, Elizabeth Mattijsen wrote:
>>  > Wouldn't you need to add taking a ref of the var, to
>>  invalidate this
>>  > optimization?  Specifically for this case:
>>  >
>>  > sub statename {
>>  >     my $name = 'david';
>>  >     ${\$name} = 'liz';
>>  >     return "hello, my name is $name";
>>  > }
>
>But surely in this case the ${\$name} should itself be optimised to $name
>first?

Well, possibly.  I just wrote it that way to be as succinct as 
possible.  I seriously doubt whether spending the extra cycles for 
checking for this particular type of situation are worth the 
optimization.



>  So it becomes
>
>sub statename {
>     my $name = 'david';
>     $name = 'liz';
>     return "hello, my name is $name";
>}
>
>And then would become
>
>sub statename {
>     return "hello, my name is liz";
>}
>
>>
>>  Then there's stuff like this, which you can't detect at compile ime:
>>
>>      sub statename {
>>	my $name = 'david';
>>	eval '$name = "liz"';
>>	return "hello, my name is $name";
>>      }
>
>You cant detect the consequence of the eval but you can detect the eval no?
>So you could disable the optimisation if there is no eval between the
>constant assignment and the stringification....

I think there are just too many ways for this optimization to go 
wrong.  Only recently another optimization I proposed ("my @list = 
()" becomes "my @list") had serious side effects that were only found 
after release.  And that was an easy one compared to the one 
suggested here.


>BTW, all of this im speaking entirely hypothetically and only out of
>curiousity as to whether im correct here.

I have no idea, I don't know the intricacies of the internals that 
well.  From a conceptual and logical point I would agree.  But I'm 
under the impression logic in Perl's internals is often burdened 
under many, many layers of (other) logical sediment.


Liz

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About