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

[Rob Savoye]

On 10/16/09 14:33, Bernie Innocenti wrote:

> > 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()

  That adds it to the garbage collector. 
http://gnashdev.org/doc/html/classgnash_1_1PropertyList.html#d7bae96d62a404a9656db68cc7aa408e. 
I just updated the doxygen pages on Gnash from trunk, the uptodate 
version is at: http://gnashdev.org/doc/html/index.html

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

  All ActionScript classes have properties, so you assume correctly.

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

  We're using Boost already, but maybe this time we should do a little 
experimenting and see what's the fastest.

> 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

  Enabling jemalloc helps, as it's more tuned towards lots of the small 
allocations both C++ and ActionScript use heavily.

> 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?

 No idea, I haven't looked at the one in Rawhide, nor Fedora 11. I've 
used my own for ages as I like to configure things differently than a 
distribution would, often enabling experimental features like avm2, or rtmp.

> 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:

  I'm often having to build branches were everything isn't all checked 
in for testing, my source directory is mounted to all the machines in my 
office. So I don't think Koji would work as well that way. Plus I also 
do *BSD, and other distributions, so being able to build my own packages 
is useful, although sometimes the maintainance is a pain in the neck.

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

  I assume the results would be mostly the same, but it'd be good to 
know if there are any differences.

        - rob -