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

MashMashy has asked for the wisdom of the Perl Monks concerning the following question:

Backstory: So, I've been tasked with shoring up a perl script that outputs all manner of information to whoever calls up the page that it is on. it pulls from a number of databases and files, parses their info, adds div tags and font tags and whatnot, and outputs it all as an HTML page. Question: the majority of the adds and blocks of 'print' are using double quotes, not single quotes. even the final block is something like
print <<__ENDER__; $info1 $info2 $info3 $info4 . . $info99 __ENDER__
where each of those info vars are their own little:
$info1="this is some sample stuff".$info_in."<br><br>";
My question - do you *really* get that much optimization from removing all the necessary double-quoted strings, and make them single-quoted?

Replies are listed 'Best First'.
Re: Optimizing Perl Code - single versus double quotes really that important?
by zentara (Archbishop) on Feb 05, 2009 at 17:42 UTC

      "In general" is misleading.

      In the particular case where you've no variables in the string, sure, maybe, but it's not an interesting use case.

      #!/usr/bin/perl use strict; use warnings; use Benchmark ('cmpthese'); my $dqv = 0; my $sqv = 0; cmpthese(1000000, { double => \&dq, single => \&sq, }); sub dq { $dqv++; my $str = "see $dqv run + and $dqv"; } sub sq { $sqv++; my $str = 'see '.$dqv.' run + and '.$dqv; }
      The difference is substantial, but only when you make perl work harder to find the variable, hence the extra spaces in the string.
      Rate double single double 943396/s -- -37% single 1492537/s 58% --

        "In general" is misleading.

        In general, concatenation/single/double quoting, is not what programs spend most/all of their time doing -- its not the bottleneck -- its not important -- its not misleading

Re: Optimizing Perl Code - single versus double quotes really that important?
by mr_mischief (Monsignor) on Feb 05, 2009 at 18:19 UTC
    ikegami pointed out already that perl will compile your string literals the same whether they use double quotes or single quotes. Why I'm strict about using single quotes and double quotes differently in my code isn't about the code's performance.

    It's about my performance. If I see double quotes and no variable, I wonder what I was planning to interpolate that isn't in the code now. If I see single quotes and a variable, I wonder for a moment why I didn't use double quotes or qq(). Parsing within the constructs is different, and I try to use the one that gives me the desired behavior. In cases in which there's no difference in final behavior, I tend to opt for single quotes just out of consistency. In my code as a rule, interpolating constructs are only used to interpolate something. The types of bugs that helps me avoid are small and simple to fix, but I've found they are quite common if I don't use the rule.

      Same here. Plus, my code editor highlights '' strings an "" strings with different colours so it helps with spotting where variable substitutions might be buried.
Re: Optimizing Perl Code - single versus double quotes really that important?
by rir (Vicar) on Feb 05, 2009 at 18:38 UTC
    No, this is a compile time thing and buys you nearly nothing performance-wise.

    The relatively recent arguments for using single-quotes on strings which have no interpolation is motivated by an intent to inform a reader whether a string literal is interpolated or not.

    In my coding, I made an extended trial of using single-quotes on all uninterpolated strings. I found the practice unproductive both as a maintainer and as an author. As a maintainer, most of my strings are not so long as to be problematic. As an author, I found double-quotes to be more flexible--too often the final interpolative nature of the string was unknown when the quotes were opened.

    It might seem that there would be more benefit to this practice when using very long strings. I did not find this to be the case; with long string literals it is work to determine if you are looking a one literal or a list or concatenation of literals.

    I'm sure experience and personal taste vary, but I find literals which are more than a line to be most easily readable in this form:

    my $usage = "This is just a literal string concat'd up; " . "it keeps significant\n" . "whitespace and interpolations in normal or " . $visible . "places. Double-quotes seem most convenient " . "just to contain simple things like newlines " . "and tabs.\n" . "But the important thing is that the dots " . "make it easy to see that each line starts\n" . "a new token\n";
    I use and like syntax highlighting, but haven't made it a prerequisite to reading code as it is not always conveniently available. I find highlighting helpful when writing to catch unterminated literals, but I tend to ignore highlighting when just reading code.

    For what it is worth, my experiment was motivated by the thought that my use of double-quotes was just a habit carried over from C.

    Be well,
    rir

Re: Optimizing Perl Code - single versus double quotes really that important?
by DStaal (Chaplain) on Feb 05, 2009 at 17:55 UTC

    Speed-wise, I don't think it makes much difference. (As has already been pointed out.) The fact that you could replace:

    $info1 = "this is some sample stuff".$info_in."<br><br>"; print <<__ENDER__; $info1 . . __ENDER__

    With:

    print <<__ENDER__; this is some sample stuff $info_in <br><br> . . __ENDER__

    Which then suggests this:

    $info[1] = "this is some sample stuff $info_in <br><br>"; .. foreach my $outfo ( @info ) { print "$outfo\n"; }

    Might be something you want to look at to do some cleanup...

      Speed-wise, I don't think it makes much difference

      Speedwise, it makes no difference. They produce exactly the same code.

      $ perl -MO=Concise,-exec -e'$x = qq{a $b c}' 1 <0> enter 2 <;> nextstate(main 1 -e:1) v 3 <$> const[PV "a "] s 4 <#> gvsv[*b] s 5 <2> concat[t3] sK/2 6 <$> const[PV " c"] s 7 <2> concat[t4] sKS/2 8 <#> gvsv[*x] s 9 <2> sassign vKS/2 a <@> leave[1 ref] vKP/REFC -e syntax OK $ perl -MO=Concise,-exec -e'$x = q{a }.$b.q{ c}' 1 <0> enter 2 <;> nextstate(main 1 -e:1) v 3 <$> const[PV "a "] s 4 <#> gvsv[*b] s 5 <2> concat[t3] sK/2 6 <$> const[PV " c"] s 7 <2> concat[t4] sKS/2 8 <#> gvsv[*x] s 9 <2> sassign vKS/2 a <@> leave[1 ref] vKP/REFC -e syntax OK

        Well...

        perl -MO=Concise,-exec -e '$x=qq{a $b c}' 1 <0> enter 2 <;> nextstate(main 1 -e:1) v:{ 3 <$> const[PV "a "] s 4 <#> gvsv[*b] s 5 <2> concat[t3] sK/2 6 <$> const[PV " c"] s 7 <2> concat[t4] sKS/2 8 <#> gvsv[*x] s 9 <2> sassign vKS/2 a <@> leave[1 ref] vKP/REFC -e syntax OK perl -MO=Concise,-exec -e '$x=q{a $b c}' 1 <0> enter 2 <;> nextstate(main 1 -e:1) v:{ 3 <$> const[PV "a $b c"] s 4 <#> gvsv[*x] s 5 <2> sassign vKS/2 6 <@> leave[1 ref] vKP/REFC -e syntax OK

        So obviously there is some minor difference at compile-time. (Which would be the only difference I expect.) Once compiled equivalent expressions produce equivalent op-code, it's just that the compile process isn't exactly the same.

        Unlikely to be noticeable though, and really irrelevant to my original reply.

Re: Optimizing Perl Code - single versus double quotes really that important?
by Anonymous Monk on Feb 05, 2009 at 18:45 UTC
    Hi, Single quoted strings for eg 'This is PERL' 'This is ${name}' in PERL are treated as literal strings. NOTE : The ${name} variable is treated as a literal string. Double quoted strings for eg "This is PERL" "This is ${name}" in PERL are also treated as strings but INTERPOLATES the ${name} variable. Hope this answers your question. - Shankar.
      Even though it's a really old post. I'd like to point out that this is not the topic which is being discussed here. The thing is we are trying to figure out if double quotes take up more resources. For instance if you use "" For every string. And replace them with '' would that make the script faster?

        So what happened when you tried it? I suggest you either read the existing replies and if still curious actually test your script.