[Live-devel] Performance

[Marc Neuberger]

Ross Finlayson wrote:
> No, that's not correct.  The RTSP server implementation's 'liveness 
> check' timer gets rescheduled only after the receipt of an incoming 
> *RTCP packet* (or an incoming RTSP command) - not on every (or any) 
> outgoing packet.
>   
Ah good, that makes a great deal more sense.
> However, I don't want to use the STL, 
> because I don't want to make the "LIVE555 Streaming Media" dependent 
> upon it (because I want this code to continue to be useful for (e.g.) 
> embedded systems that are relatively memory constrained, or which 
> might not have the STL available for other reasons).
>   
Yeah, that makes sense, too. I certainly wouldn't attempt to write the 
equivalent of the STL class (a Red-Black tree) myself. I agree that the 
current implementation is perfectly fine for most uses. Largely, I'm 
offering a tip to others that may find themselves in my situation about 
where to look for performance.
> At some point, I should get rid of these (few) remaining blocking 
> socket reads, and remove the "select()" call from "readSocket()". 
> Actually, as you're just running a RTSP server, you can probably 
> remove the "select()" call right now.  You could give that a try, to 
> see if it improves performance on your system.
>   
Yes, I did this. The figures of 400-500 sessions I quoted had the call 
to blockUntilReadable commented out.

Marc Neuberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070601/c6b8dd8b/attachment.html