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

Hello all,

Knowing TIMTOWTDI I seek advice. A core aspect of much of my Day-Job is writing CGIs that access an Oracle Database. I am in the process of developing a standard library for my programming department which uses the DBI libraries.

The question is as follows --
Currently we "eval" the "prepare" and "execute" statements in order to capture any possible errors to $@ and prevent uncontrolled bailouts from the CGI. I have however read warnings that eval can slow down execution of the entire program ( although if used once the source goes on to say, don't worry about using it again because the damage is already done. )

Is there a way to accomplish these goals without taking the hit from the eval? Also, is there an eval hidden within the prepare and execute code which makes it pointless for me to bother attempting to avoid the eval?

Thanks in advance All,
Sifmole

Replies are listed 'Best First'.
Re: DBI and Eval
by chipmunk (Parson) on Dec 20, 2000 at 19:51 UTC
    It sounds like you're using the DBI RaiseError attribute to have the DBI method calls die on error, then trapping the die with eval and doing your own error handling. If that's the case, you should just turn off RaiseError, check the return value from prepare and execute, and get the message from $DBI::errstr if there's an error.

    Anyway, as merlyn said, you've been misinformed about the performance penalty of eval. eval BLOCK does not have a performance penalty, but eval EXPR has a performance penalty every time it is executed (i.e. using eval EXPR in a loop is very inefficient).

[reply]
      Thanks Chipmunk.

      I will check out the RaiseError attribute.
      I appreciate you taking some time out to help.

[reply]
Re: DBI and Eval
by merlyn (Sage) on Dec 20, 2000 at 19:39 UTC
    A note nearly identical to this was posted to the DBI mailing list yesterday. Was that you?

    In any event, the response from those who even benchmarked it is a clear and resounding "BS" call on the "eval slows things down".

    Perhaps it's a bad bit of cargo-cult programming. eval-string certainly slows things down. Using $& (not $@) once in a program slows the whole thing down, and once you pay the price once, you don't have to pay it again. Maybe this is a mutated gene from some weird mutant merge of those two statements.

    In any event, eval-block subtracts nothing from the execution speed over the price of a normal block (now don't freak out about that either!).

    -- Randal L. Schwartz, Perl hacker

[reply]
      I wish I could remember where I thought I read that Larry said it, but combining the run-time compilation operator and the exception-handling operator seems to confuse people.

      It makes a certain amount of sense to me, as you don't want a typo in STRING to kill your whole program (and wrapping things in Java-esque try {} - catch {} is a quick way to early RSI or no more error handling), and the idea of context and different operator behavior based on argument list makes sense....

      I think people tend to think of eval as always slow, not going far enough to realize that it's only slow when it compiles something.

[reply]
      Thanks Merlyn.

      No, the question on the DBI mailing list did not come from me -- I don't even know where the list is, but might be interested in checking it out now. Thanks for the information. I think you are probably right that I merged those two statements into a bad rememberance.

      I appreciate the help.

[reply]

Back to Seekers of Perl Wisdom