Re: [Gnash-dev] performance and blocking I/O

[strk]

Eric, I haven't measured blocking reads specifically, but I think
you're right that we have a problem there.

The basics of our network streams is a curl wrapper around the tu_file
interface, which provides blocking reads.
The implementation is pretty dumb and might get better by actually
using a backtround thread for the actual download, based on callbacks
from CURL (current implementation basically polls).

When it comes to NetStream (what's used for FLV downloading), Tomas
added an additional layer (LoaderThread) which uses a thread to
continuosly read from the underlying tu_file. I think we *might* 
implement the threading thing in curl_adapter directly instead.

What I can tell is that I see (visually, looking at the system monitor),
that each curl-based load gets CPU usage very high, possible
due to the horrible poll loop in ::fill_cache.

--strk;

On Fri, May 04, 2007 at 11:53:40AM -0600, Eric Hughes wrote:
> At 10:44 AM 5/4/2007, strk wrote:
> >I've tried mapping youtube.com to localhost and providing RMS.flv as 
> >get_video.
> >CPU usage is at most 15% with this setup, so the problem is *definitely*
> >in loading/decoding process.
> 
> I can't help very specifically yet, since I'm deep in cygnal code.  I can 
> say that I threw out network.cpp entirely because I couldn't figure out how 
> to do asynchronous I/O using it with less work than writing from 
> scratch.  And furthermore I don't know enough about the details of your 
> profiling to have an assurance that I really know what I'm talking about 
> here.  Thus take the following advice _cum grano salis_.
> 
> Have you all specifically measured how much time is spent within blocking 
> reads?  The issue is CPU-time vs. real-time, that is, how much time is 
> spent doing reads vs. how much time waiting for them to complete.  Reading 
> the comment above, it struck me that this might be the difference.
> 
> If it is, I'd recommended fixing this _after_ the next release point.  I'm 
> doing single-threaded, asynchronous and non-blocking I/O in the server.  We 
> can reuse the same I/O library and scheduling discipline in the client as 
> well, but my code isn't mature enough to even start this elsewhere in the 
> code yet.
> 
> Eric
> 
> 
> 
> _______________________________________________
> Gnash-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnash-dev

-- 

 ()   ASCII Ribbon Campaign
 /\   Keep it simple!