Re: Temp variable performace vs Inline behavior

Apart from the fact that, as posted, your two snippets do different things (and the second is missing a ')'), I'd do that this way:

my @devices = grep{ defined( $_ = parse_node( $_ ) ) } @nodes;
[download]

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Comment on Re: Temp variable performace vs Inline behavior Download Code

Replies are listed 'Best First'.
Re^2: Temp variable performance vs Inline behavior by Athanasius (Archbishop) on Jun 27, 2012 at 15:37 UTC
BrowserUk’s solution: `my @devices = grep{ defined( $_ = parse_node( $_ ) ) } @nodes;` [download] is compact and efficient, but has one side-effect: the assignment to `$_` clobbers the contents of `@nodes`. In cases where this is undesirable, the following seems to do the same without the side-effect: `my @devices = grep { defined } map { parse_node( $_ ) } @nodes;` [download] Or is there a simpler way? Athanasius <°(((>< contra mundum	[reply] [d/l] [select]
Re^3: Temp variable performace vs Inline behavior by tobyink (Canon) on Jun 27, 2012 at 16:44 UTC
You could use the same technique but clobber a temporary array instead... `my @devices = grep { defined($_ = parse_node($_)) } my @tmp = @nodes;` [download] Or you could use map: `my @devices = map { my $x; defined($x=parse_node($_)) ? $x : () } @nodes;` [download] If `parse_node` was written to return the empty list in cases of failure (rather than returning the scalar undef), then it would just be: `my @devices = map { parse_node($_) } @nodes;` [download] `perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'`	[reply] [d/l] [select]
Re^2: Temp variable performace vs Inline behavior by Ransom (Beadle) on Jun 27, 2012 at 15:15 UTC
Whoops about the typo. I don't understand how they are different? I've tested my script with both and get the same results. parse_node return a nodelet on success or undef on failure. Where is the difference?	[reply]
Re^3: Temp variable performace vs Inline behavior by BrowserUk (Patriarch) on Jun 27, 2012 at 15:25 UTC
Calling `parse_node()` twice in order to avoid a temporary variable, is very unlikely to effect a performance gain. Unless `parse_node()` does almost nothing, in which case you would certainly gain more by in-lining it code in the loop. The grep solution will almost certainly prove faster. Either way, it probably isn't worth the effort unless this is likely to be called thousands or millions of times. My philosophy is "Optimise if it is worth it!". And that means concentrating ones effort where gains are likely to be measurable -- in the overall runtime. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply] [d/l] [select]
Re^3: Temp variable performace vs Inline behavior by muba (Priest) on Jun 27, 2012 at 15:17 UTC
Where is the difference? In the number of times `parse_node` is called, for starters.	[reply] [d/l]