Pro*C vs OCI
MARANDA, SEBASTIEN
I'd like to know what are the advantages of using ProC instead of OCI
and vice-versa.
If possible, Do you know where I could find some doc on the subject.
Thanks.
--
Sébastien Maranda
Solutions Informatiques en Téléphonie/
Planification des services
Computer Telephony Solutions/
Services Planning Tel.: (418) 691-3562
930 d'Aiguillon, Pag.: (418) 664-8542
Bureau 520 Fax.: (418) 691-3578
Québec, Qc, G1R 5M9 email: sebastie...@bell.ca
K. Raghuraman
OCI is a native interface with Oracle. Pro*C is the embedded code that
operate on an Oracle database. OCI is faster than Pro*C and does not
require any precompilers. OCI is pretty difficult to develop compared to
Pro*C. Also if you have any plan for migration to other databases, OCI
is not recommended as it will tie tightly to Oracle unlike Pro*C which
after suitable modifications can work in other databases. I do not know
of any document that will give more information about this.
Hope this helps.
Raghu
Nathaniel Mishkin
>operate on an Oracle database. OCI is faster than Pro*C and does not
>require any precompilers.
I'm pretty new to Oracle, but I've been writing some test programs to
investigate the performance of various operations, and to my surprise, in a
simple program that does a loop of SELECTs that return one random row from a
table, my Pro*C program was faster (by about 10-15%) than my equivalent OCI
program. I do all the OCI setup stuff outside the loop. The only OCI call
I make inside the loop is OCIStmtExecute(). I figured this would yield the
best performance, but perhaps not.
Anyone have any ideas?
--
Nat Mishkin
Rational Software
kd...@my-dejanews.com
"K. Raghuraman" <kra...@india.hp.com> wrote:
> Hi Sebastien,
>
> OCI is a native interface with Oracle. Pro*C is the embedded code that
> operate on an Oracle database. OCI is faster than Pro*C and does not
> Pro*C. Also if you have any plan for migration to other databases, OCI
I know this is a bit of a glib question, but can anyone describe how much
faster OCI is when compared to Pro*C? As Raghu mentions, OCI is much more
difficult to develop with than Pro*C. In my experience this has meant
increased development timeframes for OCI vs. Pro*C. Also, as developers
leave projects developed with OCI, maintainance issues arise as the number of
programmers with a substantial knowledge of OCI isn't very high.
Any help or observations would be appreciated.
kdas
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Rob
Proc uses after precompilation also OCI calls!
Or... am I wrong?
Rob
Thomas Kyte
(if that email address didn't require changing)
On Thu, 08 Oct 1998 21:11:50 GMT, you wrote:
>In article <35F5F13A...@india.hp.com>,
> "K. Raghuraman" <kra...@india.hp.com> wrote:
>> Hi Sebastien,
>>
>> OCI is a native interface with Oracle. Pro*C is the embedded code that
>> operate on an Oracle database. OCI is faster than Pro*C and does not
>> require any precompilers. OCI is pretty difficult to develop compared to
>> Pro*C. Also if you have any plan for migration to other databases, OCI
>
>I know this is a bit of a glib question, but can anyone describe how much
>faster OCI is when compared to Pro*C? As Raghu mentions, OCI is much more
>difficult to develop with than Pro*C. In my experience this has meant
>increased development timeframes for OCI vs. Pro*C. Also, as developers
>leave projects developed with OCI, maintainance issues arise as the number of
>programmers with a substantial knowledge of OCI isn't very high.
I didn't see the original post but...
Oci is *not* any faster then Pro*C.
OCI is an API layer on top of an API called UPI (upi is the internal, low level
Oracle API).
Pro*C precompiles into an API called SQLLIB which is a layer on top of UPI as
well.
Well code Pro*C is as fast as well coded OCI. A poorly written pro*c program
might run slower then OCI and vice versa. As long as you take advantage of
array fetching and reuse cursors as much as possible -- they offer comparable
performance.
>
>Any help or observations would be appreciated.
>
>kdas
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Thomas Kyte
tk...@us.oracle.com
Oracle Government
Herndon VA
--
http://govt.us.oracle.com/ -- downloadable utilities
----------------------------------------------------------------------------
Opinions are mine and do not necessarily reflect those of Oracle Corporation
Anti-Anti Spam Msg: if you want an answer emailed to you,
you have to make it easy to get email to you. Any bounced
email will be treated the same way i treat SPAM-- I delete it.
Thomas Kyte
(if that email address didn't require changing)
No, OCI is a layer on top of an API call UPI (upi being the low level api used
internally).
Pro*C precompiles into an API call SQLLIB which is a layer on top of UPI. Pro*c
does *not* precompile into OCI calls...
Pro*C and OCI offer comparable speed, each has advantages/disadvantages over the
other.
Bob Withers
says...
> In article <35F5F13A...@india.hp.com>,
> "K. Raghuraman" <kra...@india.hp.com> wrote:
> > Hi Sebastien,
> >
> > OCI is a native interface with Oracle. Pro*C is the embedded code that
> > operate on an Oracle database. OCI is faster than Pro*C and does not
> > require any precompilers. OCI is pretty difficult to develop compared to
> > Pro*C. Also if you have any plan for migration to other databases, OCI
>
> I know this is a bit of a glib question, but can anyone describe how much
> faster OCI is when compared to Pro*C? As Raghu mentions, OCI is much more
> difficult to develop with than Pro*C. In my experience this has meant
> increased development timeframes for OCI vs. Pro*C. Also, as developers
> leave projects developed with OCI, maintainance issues arise as the number of
> programmers with a substantial knowledge of OCI isn't very high.
>
In my experience the best thing to do is develop your own class library
built on top of OCI. I've never been happy with applications I developed
using Pro*C/C++ and I also didn't like directly embedding OCI calls in
the applications. Our own class library solved the problem and also
insulates our apps from Oracle specific interfaces.
Regards,
Bob
--
-------------------------------------------------------------------------
Bob Withers Do or do not, there is no try
bw...@pobox.com Yoda
-------------------------------------------------------------------------
Sergei Kuchin
big of a difference. OCI is more complex to learn and OCI programs are
harder to write and support. In general, it boils down to how many
people available on the market can do Pro*C and how many know OCI. I bet
a hundred bucks the number is 20-30/1. On the bright side, there's some
"wrappers" around OCI which make the use of OCI much easier. I, myself,
has been thru the question "Pro*C vs. OCI" and the answer is "it
depends." I ended up writing my own OCI "wrapper." Eventually, it became
a piece of Freeware which is avaliable at:
http://home.sprynet.com/sprynet/skuchin/otl_1pg.htm
Sergei
kd...@my-dejanews.com wrote:
>
> In article <35F5F13A...@india.hp.com>,
> "K. Raghuraman" <kra...@india.hp.com> wrote:
> > Hi Sebastien,
> >
> > OCI is a native interface with Oracle. Pro*C is the embedded code that
> > operate on an Oracle database. OCI is faster than Pro*C and does not
> > require any precompilers. OCI is pretty difficult to develop compared to
> > Pro*C. Also if you have any plan for migration to other databases, OCI
>
> I know this is a bit of a glib question, but can anyone describe how much
> faster OCI is when compared to Pro*C? As Raghu mentions, OCI is much more
> difficult to develop with than Pro*C. In my experience this has meant
> increased development timeframes for OCI vs. Pro*C. Also, as developers
> leave projects developed with OCI, maintainance issues arise as the number of
> programmers with a substantial knowledge of OCI isn't very high.
>
> Any help or observations would be appreciated.
>
Tom Poindexter
>
>I know this is a bit of a glib question, but can anyone describe how much
>faster OCI is when compared to Pro*C? As Raghu mentions, OCI is much more
"faster" means different things to different folks. "Faster development"
or "Faster execution" spring to mind.
I don't have enough recent knowledge of executions speeds between OCI and
ProC. My intution would say that anytime you hit the network, assuming
you have a two- or three-tier architecture and relatively modern hardware,
any difference OCI vs. ProC is not important.
Now, if you're talking about faster developemnt, I'd make the case that
either OCI or ProC pale in comparison to other development tools.
Modern scripting languages with database interfaces can cut development
times considerably. I'm the author of Oratcl, an Oracle interface for
the Tcl language. Oracle itself uses Tcl and Oratcl in its Oracle
Enterprise Manager product.
It might depend on what application you're trying to write; in any case,
they are worth evaluating. Follow my web page for info on Oratcl;
see www.scriptics.com or comp.lang.tcl for Tcl information.
--
Tom Poindexter
tpoi...@nyx.net
http://www.nyx.net/~tpoindex/
Susan Wilson
Ever done performance test on Oratcl compared to Pro*C or OCI? We are
going to use Oratcl (or maybe Perl's DBI modules) to talk to a Tcl suite
that runs auto-generated sw regressions tests, and stores the captured
logs to an Oracle database.
Just wondering what to expect for performance ... and btw what version
of Oracle does Oratcl support? Can I run it on Linux? Thanks in
advance.
- sooz
--
Thanks.
- Susan
Engineering System Administration
Motorola Computer Group
602-438-3765
mailto:susan_...@phx.mcd.mot.com
http://www.eng.mcd.mot.com/
Tom Poindexter
Susan Wilson <sus...@phx.mcd.mot.com> wrote:
>Tom,
>Ever done performance test on Oratcl compared to Pro*C or OCI? We are
>going to use Oratcl (or maybe Perl's DBI modules) to talk to a Tcl suite
>that runs auto-generated sw regressions tests, and stores the captured
>logs to an Oracle database.
(also answered via private email)
No, I haven't benchmarked Oratcl vs. OCI or Pro*C. Oratcl will
likely be slower in some things, but can certainly hold it's own in
other situations.
I've written GUI applications in Tcl/Tk/Oratcl that were noticably
faster (human user perception) than some written in C/OCI/Motif.
If you're writting a custom batch load program, it may be slower. A lot
depends on database design; a poorly tuned database will act slowly
no matter the front end client.
Tcl is a good fit for building a regression test harness, as evident from
several successful projects. sounds like you already have a test bench
written in Tcl. Using Oratcl will fit in very nicely.
Re: Oracle/Linux. Be sure to get the Makefile for Oracle 8.0.x I recently
posted to comp.databases.oracle.tools, or get it from my web page.
The configure/makefile that comes with Oratcl-2.5 doesn't recognize Oracle 8.
That will be fixed in Oratcl-3.0.