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

[Bernie Innocenti]

El Fri, 16-10-2009 a las 15:29 -0600, Rob Savoye escribió:
> >    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've had a look at the sources:

void
PropertyList::setReachable() const
{
    std::for_each(_props.begin(), _props.end(),
            boost::mem_fn(&Property::setReachable));
}

The first thing I notice is that the container we're iterating on is
somewhat non-trivial:

  typedef boost::multi_index_container<
    Property,
    boost::multi_index::indexed_by<
      boost::multi_index::ordered_unique<
        boost::multi_index::composite_key<
          Property, 
          
boost::multi_index::member<Property,string_table::key,&Property::mName>,
          
boost::multi_index::member<Property,string_table::key,&Property::mNamespace>
        >       
      >,    
      boost::multi_index::ordered_unique<
        boost::multi_index::tag<PropertyList::oType>,
        boost::multi_index::member<Property,int,&Property::mOrderId>
      >     
    >   
  > container;

It's hard to tell what the iterators into this monster look like, and
how much operations such as ++it and *it would cost. If one of the two
indexes is not used very frequently in real-world scenarios, there may
be a lot to be gained by switching to a simpler std::map<> and live with
some O(n) linear scans. How big is the typical n, anyway?

Secondly, the Property::setReachable() method is out of line and it also
seems non-trivial as it accesses a boost::variant<> (the mBound member):

void
Property::setReachable() const
{
    switch (mBound.which())
    {
        case 0: // Blank, nothing to do.
            break;
        case 1: // Simple property, value
        {
            boost::get<as_value>(mBound).setReachable();
            break;
        }
        case 2: // Getter/setter
        {
            const GetterSetter& a = boost::get<GetterSetter>(mBound);
            a.markReachableResources();
            break;
        }
        default:
            abort(); // Not here.
            break;
    }
}

Since boost::variant<> hides a dynamic allocation and pointer
indirection anyway, I suspect that it would cost less to create a
hierarchy below the Property class and use virtual dispatch to decide
what to do.

Even better yet, is one of the 3 types (boost::blank, as_value and
GetterSetter) flexible enough to represent the other two? Is there a
substantial saving in terms of space or time to justify the extra cost
of a boost::variant<>?

I'm just shooting at random targets here... more analysis would be
needed to determine the best course of action. I'd be curious to add a
printf() in :setReachable() to get an idea of how many values are
typically present in these PropertyLists. The current implementation
seems tuned for best scalability, which may not be necessary in
practice.


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

When I was using Boost extensively in my programs, I was often surprised
by the actual overhead of some of the most popular constructs.

Although well above average, the documentation of Boost libraries
sometimes neglects to mention important details about the implementation
and how popular compilers cope with it.

For example, shared_ptr<> costs one extra indirection on each pointer
dereference and one extra allocation per pointed object. This is not
obvious unless you take the time to look at the actual implementation,
which is as obfuscated as only heavily templated code can be.


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

Every now and thn I read about the gains of using jemalloc over standard
system allocators. Firefox and a lot of high-profile software uses it by
default.

Then I wonder: why isn't it the standard allocator in glibc yet? I'd be
curious to know what Andreas Schwab and Jakub Jelinek think about it.

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