Re: Java stored procedure performance dilemma

Hi Colin.

A few suggestions:

• Have you tried using Java native compilation (NCOMP) in order to see if that speeds your Java stored procedures sufficiently up?
• When doing string manipulations, do you use String or StringBuffer? You should use StringBuffer directly when possible since that's much more efficient.
• Have you configured the JVM with sufficiently large memory pools (init.ora parameters JAVA_POOL_SIZE, LARGE_POOL_SIZE, JAVA_MAX_SESSIONSPACE_SIZE, JAVA_SOFT_SESSIONSPACE_LIMIT)?
• Have you done internal profiling (tracing/logging messages) to determine which part of your code is slow?

HTH. Finn

"Colin McGuire" <colinandkaren_at_lycos.co.uk> wrote in message news:ab6cea37.0210161156.423d90ba_at_posting.google.com...
> I am involved with small team of programmers that have just finished
> writing a suite of Java routines that perform some grunt-job string
> manipulation/processing :- the algorithms implemented as Java stored
> procedures. Unfortunately, at this late stage in the play, performance
> has become an issue and we realise we have probably made an incorrect
> technical decision early on. Our reasons for initially choosing Java
> as the development environment were the familiar ones but platform
> independence should not have been one of the reasons as our code is
> intimately tied to Oracle. During a recent technical meeting it was
> mentioned one solution might be to rewrite (ie translate) our library
> routines from Java to Pro/C++, the latter I believe shipped with all
> flavours of Oracle and thus would run on every machine Oracle ran on,
> compile to fast native code etc. We have decided on having a think
> about this approach, weigh up the pro's and con's, and discuss again
> from an informed perspective at the next meeting.
>
> I would be interested in opinions from interested parties in the
> forum, other alternatives to our dilemma etc.
> Thank you
> Colin
Received on Sat Oct 19 2002 - 04:28:09 CDT