Re: [Gnash-dev] oprofile difficulties, easy access to debuginfo, and other thoughts

[Bernie Innocenti]

El Fri, 16-10-2009 a las 10:39 -0600, Rob Savoye escribió:
>    Ok after a few frustrating days, I've gotten oprofile to work. 
> Bizarrely, it crashed another system I was working on. Here's a log I 
> made from a YouTube video with callgraphs and symbol info. Now anyone 
> motivated should be able to get started on tracking down performance issues.
>       http://www.gnashdev.org/testcases/oprof_gnash_all.log

Very interesting.  This looks by far the hottest spot:

  gnash::PropertyList::setReachable()


I'm not familiar with Gnash's codebase, but if PropertyList is really
what its name suggests, it is a typical performance bottleneck in many
applications.

The typical C++ API for property lists is

 p->set("color", "red");
 val = p->get("color")

This requires plenty of string lookups. Using C++0x's unordered_map<> (a
hashed implementation of map<>) may slightly improve performance.
IMHO, the only way to get a big pefromance boost consists in switching
to a "handle" API:

 // called once
 color_key = p->getKey("color")

 // called many times
 p->set(color_key, "red");
 val = p->get(color_key);

Or, as a good compromise:

 // called few times
 color_key = p->set("color", "red");

 // called many times
 val = p->get(color_key);
  

Some property maps implementations I've seen try to manage typed values
using RTTI or fancy things such as boost::variant. In my experience,
this is super-inefficient compared to storing plain strings and doing
simple marshaling and unmarshaling as needed.

Here's another performance tip: most (sane) PropertyMaps tend to
allocate copies of the keys and values that are being stored in it.
typically with std::string. All these micro allocations can hurt
performance a lot. I suggest pooling allocations with a custom allocator
or even a specialized string class. Even better, allocating strings from
a pool shared by all PropertyMap instances may be a huge gain (but a
threaded application like Gnash would need locking, which may hurt
performance).

All the above is based on my speculation as I've been to lazy to check
the actual code. (maybe I will do it on Sunday if I have some time
free).


>    I seemed to have no problem with multi-threading and oprofile. I've 
> updated the gnash.spec file in Gnash trunk, it builds rpms just fine 
> now, including a working debuginfo package. (which appeared to always be 
> ok anyway). I've also been hacking on the Gnash Debian packaging files, 
> and after one more test (adjusting dependencies) I'll check them in. I 
> can now building the gnash-dbg package. The rpm and deb snapshots I've 
> uploaded to http://www.getgnash.org under fedora and karmic snapshots. 
> (both 32bit)

I'm rebuilding the srpm because I need x86_64 for my system. Are there
any notable differences between this spec and the official one in
rawhide?

Tip: if you use Koji to build the Fedora packages (as opposed to
building packages locally) you'd get builds for all architectures for
free:

  http://koji.fedoraproject.org/koji/taskinfo?taskID=1750664
  (still building)

>    My oprofile runs were built from trunk using "-g -O2", which worked 
> just fine. I've still failed to get oprofile working on the XO 1.5, I 
> get many errors about not specifying events, and other problems.

I think Chris Ball and/or Daniel Drake may be able to tell us why this
is happening.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/