Skip to Main Content

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Shimmy.

Asked: February 08, 2016 - 7:27 pm UTC

Last updated: July 26, 2017 - 4:46 am UTC

Version: 12.1.2

Viewed 10K+ times! This question is

You Asked

Hi,

Based on the following link
http://www.oracle.com/technetwork/database/features/plsql/ncomp-faq-087606.html
, it says native compilation will perform much better than the default interpreted compilation(sorry if I misinterpreted).
So, why can't we compile all PL/SQL in native mode by default?
Are there any dis-advantage to native compilation?

Thank you

and Connor said...

"So, why can't we compile all PL/SQL in native mode by default?"

You can. You could alter parameter plsql_code_type at database level and you're ready to go. There are also scripts to recompile all existing PLSQL if you wanted to go that way.

I don't see any disadvantage to doing so - but generally we (ie Oracle) dont change the default for something system-wide because of backward compatiblity reasons. Similarly, earlier versions of the database required you to both have your own compiler license plus the compiled objects where stored outside the database, hence backup consistency issues had to be catered for.

But also dont forget - in my experience, 90% of PLSQL code is accessing or manipulating data in the database. The speed of that is unaffected by how PLSQL is compiled. Its the processing done purely *within* PLSQL that will be faster. So if you've got lots of logic etc in the PLSQL code itself, then by all means, give native a test.




Rating

  (1 rating)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Native is not much faster

Dmitrii Dunaev, July 10, 2017 - 6:07 am UTC

Hello everyone.

I wanted to just play with the native compilation and see how it works. I knew I probably would never implement it because pretty much every pl/sql code we have issues DML statements against the database. But I though I would give it test.

Many posts I've seen online claim that if you do not use SQL statements you can get up to 20 times faster performance. And they provide a simple code like this:

CREATE OR REPLACE PROCEDURE test_speed AS
v_number NUMBER;
BEGIN
FOR i IN 1 .. 1000000 LOOP
v_number := i / 1000;
END LOOP;
END;
/

and then compile it both in NATIVE and INTERPRETED modes and compare the result. I did the same exact tests on my installation (12.1.0.2.0) and saw only maybe 10% of improvement.
My question is why? Has 12c version of pl/sql interpreted mode gotten so good that it almost beats native compilation?

Thank you in advance.
Connor McDonald
July 26, 2017 - 4:46 am UTC

It is generally for specific use cases, and careful selection of data types that will see the most benefit, eg

SQL> CREATE OR REPLACE PROCEDURE test_speed AS
  2  i simple_integer := 0;
  3  v_number simple_integer := 0;
  4  BEGIN
  5  LOOP
  6  v_number := i + 1000;
  7  i := i + 1;
  8  exit when i > 1000000000;
  9  END LOOP;
 10  END;
 11  /

Procedure created.

SQL> set timing on
SQL> alter session set plsql_code_type = native;

Session altered.

SQL> alter procedure test_speed compile;

Procedure altered.

SQL> exec test_speed;

PL/SQL procedure successfully completed.

Elapsed: 00:00:02.68

SQL> alter session set plsql_code_type = interpreted;

Session altered.

SQL> alter procedure test_speed compile;

Procedure altered.

SQL> exec test_speed;

PL/SQL procedure successfully completed.

Elapsed: 00:00:16.61


but seeing as PL/SQL is commonly used as a means of efficient *data* access, the benefits for native are perhaps smaller in the general case.
more

Connor and Chris don't just spend all day on AskTOM. You can also catch regular content via Connor's blog and Chris's blog. Or if video is more your thing, check out Connor's latest video and Chris's latest video from their Youtube channels. And of course, keep up to date with AskTOM via the official twitter account.