gnash-dev
[Top][All Lists]
Advanced

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

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


From: Rob Savoye
Subject: Re: [Gnash-dev] oprofile difficulties, easy access to debuginfo, and other thoughts
Date: Fri, 16 Oct 2009 15:29:19 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-2.7.b4.fc11 Thunderbird/3.0b4

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 -




reply via email to

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