http://www.perlmonks.org?node_id=163301


in reply to Re: Re: Idiomatic optimizations
in thread Idiomatic optimizations

On an otherwise unloaded P4 1.g GHz

For certain very specific meanings of the word "unloaded", I'm sure. "foo" is optimized to 'foo' at compile time, so neither of them can possibly be faster. As you can see, the generated bytecode is equivalent: 

2;0 juerd@ouranos:~$ perl -MO=Concise -e'$foo = "foo"'
6  <@> leave[t1] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 1 -e:1) v ->3
5     <2> sassign vKS/2 ->6
3        <$> const(PV "foo") s ->4
-        <1> ex-rv2sv sKRM*/1 ->5
4           <$> gvsv(*foo) s ->5
-e syntax OK
2;0 juerd@ouranos:~$ perl -MO=Concise -e'$foo = '\''bar'\'
6  <@> leave[t1] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 1 -e:1) v ->3
5     <2> sassign vKS/2 ->6
3        <$> const(PV "bar") s ->4
-        <1> ex-rv2sv sKRM*/1 ->5
4           <$> gvsv(*foo) s ->5
-e syntax OK

[download]
Even "Hello, $name!" is optimized to 'Hello, ' . $name . '!'.

Note: I _do_ think people should use single quotes when not interpolating. It saves you a lot of hits on the backslash key, and avoids getting bitten by: "$You're kidding me" (eq. "$You::re kidding me"), "my@emailaddress.com" (intended: "my\@emailaddress.com"). 

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

Replies are listed 'Best First'.
Re: Re: Re: Re: Idiomatic optimizations
by belg4mit (Prior) on May 01, 2002 at 17:00 UTC
    >For certain very specific meanings of the word "unloaded"
    Yes of course, namely 0.0 (!) And we've already established that the bytecode is *supposedly* the same, afterall is it not true that Deparse is not guaranteed to reconstruct things exactly? So this adds nothing new. It does not help describe the erratic behavior.

    --
    perl -pew "s/\b;([mnst])/'$1/g"

[reply]

      afterall is it not true that Deparse is not guaranteed to reconstruct things exactly

      It is true that Deparse is not guaranteed to reconstruct things exactly. That's why I did use B::Concise, not B::Deparse. It prints the generated bytecode in a semi-readable way, it does not re-construct Perl code.

      The bytecode isn't "supposedly" the same, it IS the same. You could use B::Bytecode to get the raw bytecode (Can't paste because of its binary format), and you could use diff to check their being equivalent. Only compile-time can differ with single/double quotes, so had you benchmarked eval q/$foo = 'foo'/ versus eval q/$foo = "foo"/, you could have gotten some difference. Run-time can, as far as I can see with all the nice tools that let you dig into the generated bytecode, not be different for "foo" versus 'foo', unless when they're evaluated in different circumstances. A load of 0.00 does not mean your system is doing absolutely nothing, as the number is the _average_ number of instructions waiting in a _queue_. If your system is capable of handling simple instructions immediately, you can have a somewhat loaded system with a 0.00 "load average" number.

      This indeed does not give any information as to why you got these strange - and as far as I can test impossible - results, but as all my tests (and not only mine) on different systems tell me that "foo" versus 'foo' is a tie, I think you shouldn't trust your benchmark results. Have you been benchmarking using eval STRING, or anything else that makes difference on run-time? 

      - Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

[reply]
        The system was idle, trust me, nothing happening. And no, no evals on my part. I simply cut and paste the benchmarking code used by BlueLines HOWEVER, scrutinizing the Benchmark code reveals that *it* in fact string evals.

        --
        perl -pew "s/\b;([mnst])/'$1/g"

[reply]

In Section Meditations