[CMI.PM] Re: Perl Debugger and finding CPU Usage

[Arun Bhalla]

Mitch Kutzko writes:
> At 09:35 PM 11/7/2003 -0600, Arun Bhalla wrote:
> > Well, I think now it's time to look at the code.  I've never seen Net::RTP
> > before.  It looks like rtp_recv is either inefficient or is being
> > used incorrectly.  Perhap you can look through the Net::RTP code and
> > figure out what's going on.
> 
> Hi, Arun....
> 
> The Net::RTP code is the RAT (Robust Audio Tool) rtp.c common library
> (v1.2.14) run through SWIG to make it available to Perl.  It should be
> pretty solid, since it's recent, and it's been pounded on a bunch for a
> long time by lots of folks.
> 
> However, I'm wondering about my call to it.  I had trouble with the socket
> stuff earlier on, where I wasn't getting all the data from the connection
> -- This seemed to clear it up, but now I wonder if it's not hanging up
> somewhere.  Does this look clean to you?
> 
> 
> 
> # Continue to loop until rtp_recv returns FALSE -- Read 
> # *all* the data, not just one packet's worth.
> # 	Args: What are we listening to, how long can we block, and when did we
> get it?
> while (rtp_recv($session, $timeout, $rtp_ts)) { 
> 	rtp_update($session);
> }

Given that information ;-), my best guess is that the timeout may be too
short, causing for rtp_recv to be called too frequently.  However, it would
appear that rtp_recv is never timing out -- I would assume that rtp_recv
would return false on timeout, and thus the while loop would end.  Also, I
imagine that your client has certain constraints on proper timeouts.  Still,
I suppose it's worth a shot trying to change the timeout, seeing if
it improves performance and doesn't break your code.

Otherwise maybe you need to check other aspects, such as how your
socket/session are initialized and seeing which parameters are set and
which are not.

Arun