Re: Java stored procedure performance dilemma

For me
Pro C is the final (well not final - there's always assembly called from a C wrapper )
solution for absolute speed in something like this.

However I've been programming C since 1988 and there are only a few cases where it's actually needed

perhaps for example a 'roll-your-own-super-fast-sort that takes full advantage of the processor' but as databases and OS's get better then the need for this gets less and less.

As someone else said ... there may be a better way... PL/SQL....

what kind of profiling have you guys done "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 Thu Oct 17 2002 - 05:12:40 CDT