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! _______________________________________________ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
