Home » Developer & Programmer » Precompilers, OCI & OCCI » tracing performance of a pro*C code (HP Unix)
icon5.gif  tracing performance of a pro*C code [message #292001] Mon, 07 January 2008 07:15 Go to next message
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.

Re: tracing performance of a pro*C code [message #292003 is a reply to message #292001] Mon, 07 January 2008 07:19 Go to previous messageGo to next message
Michel Cadot
Messages: 64152
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
Re: tracing performance of a pro*C code [message #292334 is a reply to message #292001] Tue, 08 January 2008 10:02 Go to previous messageGo to next message
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?
Re: tracing performance of a pro*C code [message #292340 is a reply to message #292334] Tue, 08 January 2008 10:51 Go to previous messageGo to next message
Michel Cadot
Messages: 64152
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
I use "printf" with time.

Regards
Michel
Re: tracing performance of a pro*C code [message #292523 is a reply to message #292340] Wed, 09 January 2008 02:13 Go to previous messageGo to next message
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.
Re: tracing performance of a pro*C code [message #292524 is a reply to message #292523] Wed, 09 January 2008 02:15 Go to previous messageGo to next message
Michel Cadot
Messages: 64152
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
Re: tracing performance of a pro*C code [message #294037 is a reply to message #292524] Wed, 16 January 2008 03:13 Go to previous message
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.
Previous Topic: OCI API's details
Next Topic: How to get the value of varchar 2?
Goto Forum:
  


Current Time: Sat Dec 10 05:11:53 CST 2016

Total time taken to generate the page: 0.21863 seconds