OraFAQ Forum: Precompilers, OCI & OCCI » tracing performance of a pro*C code

Home » Developer & Programmer » Precompilers, OCI & OCCI » tracing performance of a pro*C code (HP Unix)

Show: Today's Messages :: Polls :: Message Navigator
E-mail to friend

tracing performance of a pro*C code [message #292001]

Mon, 07 January 2008 07:15

pedro_num1
Messages: 4
Registered: January 2008

Junior Member

Hello,

I want to know how to trace performance of a pro*C source code. It compiles and generates a shared library.

Also let me know tips on optimising the performance of the same. Right now I am trying to reduce redundant SQL calls.

Report message to a moderator

Re: tracing performance of a pro*C code [message #292003 is a reply to message #292001]

Mon, 07 January 2008 07:19

Michel Cadot
Messages: 68418
Registered: March 2007
Location: Nanterre, France, http://...

Senior Member
Account Moderator

The same way as any other C program: intrumentalize it, put probes in it.

Regards
Michel

Report message to a moderator

Re: tracing performance of a pro*C code [message #292334 is a reply to message #292001]

Tue, 08 January 2008 10:02

pedro_num1
Messages: 4
Registered: January 2008

Junior Member

Thank you very much Michel for your reply. What kind of probes and instrumentalization are we talking about here? Are there any reference documents which I can look up to do what you are saying?

Report message to a moderator

Re: tracing performance of a pro*C code [message #292340 is a reply to message #292334]

Tue, 08 January 2008 10:51

Michel Cadot
Messages: 68418
Registered: March 2007
Location: Nanterre, France, http://...

Senior Member
Account Moderator

I use "printf" with time.

Regards
Michel

Report message to a moderator

Re: tracing performance of a pro*C code [message #292523 is a reply to message #292340]

Wed, 09 January 2008 02:13

pedro_num1
Messages: 4
Registered: January 2008

Junior Member

Hi Michel, I did that already, but it wasn't giving any clear picture. suppose my application is taking two hours (it basically generates a flat file) 20-30 mins is taken for a cursor to open then the printf hardly takes a second each to format the record. So it becomes hard to judge which part of the code is taking too much time.

Report message to a moderator

Re: tracing performance of a pro*C code [message #292524 is a reply to message #292523]

Wed, 09 January 2008 02:15

Michel Cadot
Messages: 68418
Registered: March 2007
Location: Nanterre, France, http://...

Senior Member
Account Moderator

If it takes so long to open (and execute before fetching) a cursor then you have to optimize the SQL statement.

Regards
Michel

Report message to a moderator

Re: tracing performance of a pro*C code [message #294037 is a reply to message #292524]

Wed, 16 January 2008 03:13

pedro_num1
Messages: 4
Registered: January 2008

Junior Member

Hi Michel, Unfortunately the cursor query is already optimized Sad

, In a way the code is also but the requirement is to reduce more time. One thing I did is to reduce redundant SQL calls. This SQL call was per record if some value in record are repeated then that call isn't made. I can send you the source code if you want.

Report message to a moderator

Previous Topic:	OCI API's details
Next Topic:	How to get the value of varchar 2?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Mar 28 03:42:52 CDT 2023