Re: Native compiled code *much* slower??

Hi, Steve.

Seems that you have a bit abnormal performance problem.

Sorry, I don't have an answer, but why don't you get back to the basics of
the performance troubeshooting?

For example...

1. PL/SQL profiling - dbms_profiler
2. Oracle callstack trace analysis - errorstack dump and/or short_track
3. OS system call analysis - strace/truss/....
4. Even 10046 trace would help(sometimes) in case you have queries in the
PL/SQL block.
5. Misc.

Cheers.

================================
Dion Cho - Oracle Performance Storyteller

http://dioncho.wordpress.com (english)
http://ukja.tistory.com (korean)
http://dioncho.blogspot.com (japanese)
http://ask.ex-em.com (q&a)
================================


2009/12/24 Steve Baldwin <stbaldwin@xxxxxxxxxxxxxxxx>

> Hi Toon,
>
> Should it matter?  I thought that *everything* was at least as fast
> native compiled.  From the Oracle docs ...
>
> "Because native compilation applies only to PL/SQL statements, a
> PL/SQL unit that only calls SQL statements might not run faster when
> natively compiled, but it does run at least as fast as the
> corresponding interpreted code. The compiled code and the interpreted
> code make the same library calls, so their action is the same."
>
> I have tried a trivial package and the natively compiled package was
> marginally faster than interpreted however the package I'm testing
> here is pretty much all PL/SQL code so I expected it to be
> significantly faster, not 100x *slower*.
>
> I guess now it's a matter of trying to pull it apart to find out what
> is causing the slowdown.
>
> Has anyone seen significant improvement using native compilation?
>
> Thanks,
>
> Steve
>
> On Thu, Dec 24, 2009 at 6:48 PM, Toon Koppelaars
> <toon.koppelaars@xxxxxxxxxxx> wrote:
> > What's in: msc$log_p?
> > And in sb2.sql?
> >
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

Other related posts: