in reply to The Cost of Nested Referencing

The way hashes work, Perl cannot optimize $hash{constant_key} for you. There was an article on Perl.com which explained them recently; read it and think about it a bit.

Makeshifts last the longest.

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]

      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]

In Section Meditations