Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Does eval cause that much of a performance hit?

by sherab (Scribe)
on May 06, 2009 at 02:40 UTC ( #762138=perlquestion: print w/ replies, xml ) Need Help??
sherab has asked for the wisdom of the Perl Monks concerning the following question:

Hello brothers and sisters,
I have recently started a new job developing perl with some definite perl advocates but they tend to be older guys and prefer things like a three line if construct than a trailing if.

That being said, I'm certainly no perl expert, but I have discovered a technique that I enjoy. The technique revolves around situations when a number of tests need to be conducted.

My technique is to place tests into either a hash or array and then eval them via map.

The criticism I get is that eval causes a performance hit that may not be worth it. I have been called out on a couple of issues that later proved to be correct on my part so I tend to verify everything now.

If I have a series of 15 tests I have to perform, 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 ......
if { test condition }
I also just find this way to be plain easier to add new tests if need be.

Should I really be concerned about performance hits? Does eval REALLY cause that much of a performance issue?

Respectfully,
Sherab

Comment on Does eval cause that much of a performance hit?
Download Code
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 :)

      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
        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 ...

Re: Does eval cause that much of a performance hit?
by spx2 (Chaplain) 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.
      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.

        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

        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 !

        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.

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;

    Again, theres lots of other options besides even this one.

    regards,

Re: Does eval cause that much of a performance hit?
by lostjimmy (Chaplain) on May 06, 2009 at 04:57 UTC
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;
      They're only right about that one case :) the rest is subjective

      What are the alternatives:

      my $foo; if( $baz ) { $foo = $bar; }

      Or

      my $foo; $foo = $bar if $baz;

      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;

      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.
        What are the alternatives

        An alternative to your alternatives

        my $foo = defined($baz) ? $bar : undef;

        or, with a sensible default, as an explicit undef is pretty dumb,

        my $foo = defined($baz) ? $bar : 0;

        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

        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.

Re: Does eval cause that much of a performance hit?
by tweetiepooh (Friar) 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.

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' . .
    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 :-))
      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.
Re: Does eval cause that much of a performance hit?
by GrandFather (Cardinal) 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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://762138]
Approved by ww
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (8)
As of 2014-08-21 12:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (134 votes), past polls