Re: native vs interpreted compilation

Hello JChirco, I evaluated native compilation and it was enough faster to use it, I don't remember the times, but the database creation was slower. I move to navite all database procedure creating the database from zero, and exporting to it to test it.

:)

2016-11-03 8:24 GMT-04:00 Mark W. Farnham <mwf_at_rsiz.com>:

> If many calculations are done in your PL/SQL code it can be a big win.
>
>
>
> If the dominant action of your PL/SQL code is to submit SQL to the
> database in a structured way and procedurally manage the results as an API,
> then there is less advantage.
>
>
>
> I hope those are reasonable examples of the polar cases.
>
>
>
> If you have a big suite of interrelated code where some patch might
> routinely trigger thousands of things to be recompiled, then you should be
> aware of the marginal difference in compilation time that may be required.
> For example if you have the E-biz suite, you might target only calculation
> heavy packages for native compilation if you are applying an update.
>
>
>
> I cannot recall a bug difference amongst the levels of compilation.
>
>
>
> I cannot put my fingers on the recommendation guidelines at the moment,
> but it is either in the documentation or some paper by Bryn Llewellyn in
> the general case or memos from the E-biz Application Technology Stack team
> in that specific case. Those should be easy to find.
>
>
>
> mwf
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_
> freelists.org] *On Behalf Of *Jeff Chirco
> *Sent:* Wednesday, November 02, 2016 3:35 PM
> *To:* oracle-l_at_freelists.org
> *Subject:* native vs interpreted compilation
>
>
>
> How much has everyone seen or used native compilation? From what I have
> read native compilation is generally the same or faster execution than
> interpreted. So I guess what would be reasons to not run native. Any
> gotchas?
>
> 11.2.0.4 database currently.
>

--
http://www.freelists.org/webpage/oracle-l