[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] IO performance

From: strk
Subject: [Gnash-dev] IO performance
Date: Mon, 1 Jun 2009 23:40:05 +0200

Profiling of Gnash by Andrea on Amiga OS brought back
to my attention performance of Gnash IO operations.

He found out that the 100% CPU usage there is due
to the far too many small file reads Gnash performs.

This is a known issue I tried to deal with a few times
in the past w/out committing any big improvement yet,
but I'm sure there's a lot to do.

The first problem is the *need* we have for small reads
from IOChannel (formerly known as tu_file) from the Gnash
parsers (SWF and FLV). The need arises from the parser model
which is a pull parser, fetching even bits by bits for the SWF

A first approach at reducing the problem was the caching gnash::stream
patch which you can find here:

That patch probably doesn't apply to trunk anymore, but the idea
was that at least the SWF parser would fetch full tags and keep
them in memory.

Another spot we may optimize are the actual ::fread calls
in the curl and filedescriptor adapters. They currently read
in chunks of 1 byte, but could easily be switched to read
in bigger chunks, namely as many as requested by caller.
This might not make a big difference until the callers actually
ask for bigger chunks, but it's a start.

Yet another approach would be using mmap and let the system
do its best to make reads faster.

I guess the main problem here would be profiling as gprof won't
notice the amount of time spent there, similarly to how allocation
costs went unnoticed in the ninja case.

If anyone is ready to profile patches I'm willing to give some
for evaluation.


 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign  /\  Keep it simple! 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]