Re: The Cost of Nested Referencing

Replies are listed 'Best First'.
Re: Re: The Cost of Nested Referencing by shotgunefx (Parson) on Nov 16, 2002 at 02:17 UTC
I don't know if there isn't any way such an optimization would be possible in certain cases, but it's only useful in certain contexts so probably wouldn't be worth it to implement it into perl itself. I guess I assumed it did this optimizing because it can't detect nested assignments in TIEs. I assumed it went right to the nested reference. Since it appears to hit every key, I am a bit perplexed as to why it cannot catch nested stores and retrieves, but that's a different problem for another day. -Lee "To be civilized is to deny one's nature."	[reply]
Re^3: The Cost of Nested Referencing by Aristotle (Chancellor) on Nov 16, 2002 at 02:41 UTC
It could do that, if it was smart enough to look around that far in the code. In reality, the optimizer is really rather dumb. If you say `perl -MO=Deparse,-x7` you'll get to see exactly what the compiler has done to your code, the `-x7` switch tells B::Deparse not to rearrange constructs in order to prettify them. The code you see in in that dump will be exactly what `perl` is going to execute; anything that's mentioned twice there will actually be done twice. Poke around and you'll see that the compiler's optimizer is really quite limited and mainly implements a few highly specialized shortcuts. The reason the compiler can't set lookups to constant keys in stone is that the hash itself is not set in stone, and as you add or delete keys, things shift about. I suppose at least some shortcuts might still be possible, but, well - given the general level of ignorance of the optimizer.. Makeshifts last the longest.	[reply]


"be consistent"
	PerlMonks