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

[Benjamin Wolsey]

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

I think the multi container was introduced at a point when properties
were always ordered lexicographically by default. The multi-index added
a 'slot' concept that at least for AS2 reflects property creation order.
 
It turned out this is the correct way to enumerate properties, and there
is no need for the lexicographic index. So it's perfectly possible to
use a map instead. It would certainly have some savings in memory use.
For speed I'm not sure. I did try replacing the boost container with a
map once and noticed no difference, but I didn't try on a machine where
GC performance is a problem.

The current Property container handling does ugly things with const that
are also largely avoidable using a map, so it certainly has benefits for
readability. 

> How big is the typical n, anyway?

For SWF-created objects probably under 10. For classes in the player API
there is a property for each function, constant, and getter-setter, as
well as prototype, constructor etc. Anything up to 40 or 50. For arrays,
which as of last week now also use normal properties, it could be
thousands (but mostly isn't for the very reason that AS2 arrays'
inefficiency is well-known).

> I'm just shooting at random targets here... more analysis would be
> needed to determine the best course of action.

Yes... Creating stress tests for property lists wouldn't be hard - both
for small and large ones. 

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

It's no secret that shared_ptr<> has non-negligible overhead when other
smart pointers have very little (or in some cases none). We shouldn't be
using it (I don't think we are) for anything that will be allocated very
frequently. 


--
The current release of Gnash is 0.8.5
http://www.gnu.org/software/gnash/

Benjamin Wolsey, Software Developer - http://benjaminwolsey.de

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil