Does eval cause that much of a performance hit?

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

Replies are listed 'Best First'.
Re: Does eval cause that much of a performance hit? by spx2 (Deacon) on May 06, 2009 at 03:46 UTC
You could read this and this , profile/benchmark your code and then find out if your co-workers are right or wrong , and maybe you can come back and tell us the results also.	[reply]
Re^2: Does eval cause that much of a performance hit? by sherab (Scribe) on May 06, 2009 at 03:52 UTC
Thanks spx2! It's a federal agency I work for and we aren't able to install modules without a VERY good reason. Totally love these two suggestions though.	[reply]
Re^3: Does eval cause that much of a performance hit? by ELISHEVA (Prior) on May 06, 2009 at 04:03 UTC
It is a bit more work, but you can also write two comparison scripts and do several runs each with Devel::DProf, which is a core module. However, nothing stops you from putting Perl on your personal laptop, installing the modules, and writing a little benchmark test with some sample conditions. Don't use the federal test data of course! For various tips on installing CPAN, see Yes, even you can use CPAN. In either case, make sure you do several runs of each. When profiling there can be a wide variance in the results depending on what other system/app processes just happen to be running on your computer at the same time. Best, beth	[reply]
Re^3: Does eval cause that much of a performance hit? by spx2 (Deacon) on May 06, 2009 at 04:06 UTC
It's a federal agency I work for and we aren't able to install modules without a VERY good reason Wouldn't want to upset the Federal Agency eh ? Devel::DProf and Benchmark are Perl Core modules , that means they come with Perl so you needn't install anything , and it's *legal* also , so use Perl Core modules , stay legal , don't get busted please !	[reply]
Re^3: Does eval cause that much of a performance hit? by ig (Vicar) on May 06, 2009 at 04:55 UTC
If the issue is installation of new/unapproved modules into the system libraries, rather than the use of them in general, you may be able to install them in a personal library or application specific library. All you have to do to use modules from non-standard locations is add the non-standard library directory to @INC. I have also found Devel::NYTProf a useful profiling module.	[reply]
Re: Does eval cause that much of a performance hit? by trwww (Priest) on May 06, 2009 at 04:24 UTC
Hello, You've posed your question with what seems like an assumption that your only options are eval or a big long conditional. The fact of the matter is, you have a multitude of other options. It sounds to me like you need to make an array of subroutines for your tests and execute those in your map: `my @tests = ( sub { ... }, sub { ... }, ); my @results = map $_->(), @tests;` [download] Again, theres lots of other options besides even this one. regards,	[reply] [d/l]
Re: Does eval cause that much of a performance hit? by lostjimmy (Chaplain) on May 06, 2009 at 04:57 UTC
Similar to what trwww said, you might want to take a look at using dispatch tables. A couple of nodes that discuss them: When should I use a dispatch table? and Implementing Dispatch Tables.	[reply]
Re: Does eval cause that much of a performance hit? by Anonymous Monk on May 06, 2009 at 03:28 UTC
I would much prefer to put the 15 tests in a hash, iterate over the keys and do that instead of writing 45 lines of .... plain easier to add new tests if need be. It appears your reasons are aesthetic, can you elaborate on your reasons? Should I really be concerned about performance hits? Maybe. The rule of thumb is if it seems slow, or you need to run it often, try to make it faster. Does eval REALLY cause that much of a performance issue? :) Can you quantify REALLY and that much ? eval EXPR is parsed and executed as if it were a little Perl program. So instead of parsing/executing one Perl program, you have one plus X many little ones. 1+X is slower than 1 :)	[reply]
Re^2: Does eval cause that much of a performance hit? by sherab (Scribe) on May 06, 2009 at 03:49 UTC
It appears your reasons are aesthetic, can you elaborate on your reasons? If preferring not having to read 45 lines of if{} in favor of much fewer then yes it is aesthetic. It just seems that 45 lines of if {} is just unnecessary and redundant. If there are 15 tests and I can see all 15 without having to page down then all the better. Maybe. The rule of thumb is if it seems slow, or you need to run it often, try to make it faster. It would take official benchmarking to determine that. It's negligable in real terms IMHO. :) Can you quantify REALLY and that much ? eval EXPR is parsed and executed as if it were a little Perl program. So instead of parsing/executing one Perl program, you have one plus X many little ones. 1+X is slower than 1 :) Ah now we're getting to a golden nugget. Seeing that eval EXPR is parsed and executed as if it were a little program and then having that eval to happen 15 times does answer my question to a degree although I believe the answer is going to involve a benchmark every time I want to make the point that using eval is negligable. I appreciate your input on this. Sherab	[reply]
Re^3: Does eval cause that much of a performance hit? by Anonymous Monk on May 06, 2009 at 04:22 UTC
It just seems that 45 lines of if {} is just unnecessary and redundant How? Instead of typing `if(code){code}` you type `q{code},q{code}` (or `'code' => 'code'`) just so it would fit on one page? That is very superficial, and I dare say, juvenile. Much much better idea would be to limit file size to what fits on one screen, say 30 lines ...	[reply] [d/l] [select]
Re: Does eval cause that much of a performance hit? by perrin (Chancellor) on May 06, 2009 at 05:24 UTC
they tend to be older guys and prefer things like a three line if construct than a trailing if Listen to your elders! They're right. And don't let me catch you writing this: `my $foo = $bar if $baz;` [download]	[reply] [d/l]
Re^2: Does eval cause that much of a performance hit? by BrowserUk (Patriarch) on May 06, 2009 at 08:50 UTC
What are the alternatives: `my $foo; if( $baz ) { $foo = $bar; }` [download] Or `my $foo; $foo = $bar if $baz;` [download] Of course, if you're setting `$foo`, then presumably your gonna use it at some point later. And unless your enamoured with testing every variable for undef prior to using it, then in most cases there is a sensible default that it can be initialised to. In which case: `my $foo = 0; $foo = $bar if $baz;` [download] Of course, that can be done "long hand" also if that's you preference. And that's the point. Using this particular flaw in the Perl semantics as a justifiction for a style preference is disingenuous. 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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l] [select]
Re^3: Does eval cause that much of a performance hit? by grinder (Bishop) on May 06, 2009 at 13:38 UTC
What are the alternatives An alternative to your alternatives `my $foo = defined($baz) ? $bar : undef;` [download] or, with a sensible default, as an explicit undef is pretty dumb, `my $foo = defined($baz) ? $bar : 0;` [download] This saves at least a nextstate and an assignment, for no loss of readability. • another intruder with the mooring in the heart of the Perl	[reply] [d/l] [select]
Re^4: Does eval cause that much of a performance hit? by BrowserUk (Patriarch) on May 06, 2009 at 13:50 UTC
Re^5: Does eval cause that much of a performance hit? by grinder (Bishop) on May 06, 2009 at 15:02 UTC
Re^3: Does eval cause that much of a performance hit? by perrin (Chancellor) on May 06, 2009 at 20:03 UTC
I was teasing. I use trailing if, although only in certain circumstances: it fits on one line without any obfuscation and it's an interrupt, like a next or return. But the flaw I pointed out with "my...if" is serious and scary and everyone should be aware of it.	[reply]
Re^4: Does eval cause that much of a performance hit? by BrowserUk (Patriarch) on May 06, 2009 at 20:22 UTC
Re^2: Does eval cause that much of a performance hit? by Anonymous Monk on May 06, 2009 at 08:06 UTC
They're only right about that one case :) the rest is subjective	[reply]
Re: Does eval cause that much of a performance hit? by tweetiepooh (Hermit) on May 06, 2009 at 10:43 UTC
You also have to make your code understandable to others. No good being clever if no-one else can maintain your code. That's not clever, that's stupid. Coding rules in an organisation are there to maintain standards and easy transfer of code between people. There maybe better ways and times to break those standards but then discuss them through, find out why things are the way they are and demonstrate your new ways are acceptable and when.	[reply]
Re: Does eval cause that much of a performance hit? by Bloodnok (Vicar) on May 06, 2009 at 12:46 UTC
I wholeheartedly empathise ... it rather sounds like you're in a similar situation to myself whereby excessive verbosity and mostly unnecessary comments e.g. comments almost identical to the code, is preferred over readability and elegance. The preference resulting in, IMO, almost impenetrable code e.g.... `# Declare the array @array = (); # Initialise the array $array[0] = 'something'; $array[1] = 'something_else' $array[2] = 'something_more' . .` [download] Note also the, not atypical, lack of strictures. I've found (the hard way) that the best way to approach it [the problem] is to, initially, find the lowest common denominator - thereafter both advocating education and demonstrating the benefits of the more elegant approach alongside the traditional approach for all to see... A user level that continues to overstate my experience :-))	[reply] [d/l]
Re^2: Does eval cause that much of a performance hit? by Anonymous Monk on May 06, 2009 at 12:53 UTC
I've read this thread a few times now, and that doesn't sound like the case at all :) eval EXPR can never be a solution for readability.	[reply]
Re: Does eval cause that much of a performance hit? by GrandFather (Saint) on May 06, 2009 at 21:26 UTC
Show us some sample code! Without an example I'm struggling to understand in detail what you are actually doing. I strongly suspect there are better ways to achieve your end than using eval however. True laziness is hard work	[reply]


good chemistry is complicated, and a little bit messy -LW
	PerlMonks