[Gnash-dev] IO performance

[strk]

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
case.

A first approach at reducing the problem was the caching gnash::stream
patch which you can find here: 
https://savannah.gnu.org/patch/index.php?6334

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.

--strk; 

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple!