> The main culprit for 16-byte allocations seems to be: > CPU ID FUNCTION:NAME > 0 69953 malloc:entry > libc.so.1`malloc > libCrun.so.1`void*operator new(unsigned)+0x38 > libgnashcore-0.8.6.so`void > gnash::DisplayObject::queueEvent(const gnash::event_id&,int)+0x35 > libgnashcore-0.8.6.so`void gnash::MovieClip::advance()+0xfc > libgnashcore-0.8.6.so`void > gnash::movie_root::advanceLiveChar(boost::intrusive_ptr<gnash::DisplayObject>)+0x72 > libgnashcore-0.8.6.so`__type_1 > std::for_each<std::_List_iterator<gnash::DisplayObject*,std::_Nonconst_traits<gnash::DisplayObject*> > >,boost::_bi::bind_t<void,void(*)(boost::intrusive_ptr<gnash::DisplayObject>),boost::_bi::list1<boost::arg<1> > > > >(__type_0,__type_0,__type_1)+0x41 > libgnashcore-0.8.6.so`void > > I get a similar preponderance of 16-byte allocs with other Flash movies. > Maybe QueuedEvent objects could be created by a different method?
All the ExecutableCode subclasses with the exception of EventCode are trivial enough to copy. They use new because they have to be polymorphic. It may be possible to change that, but it's not simple. For stack-based polymorphism, boost::variant with a static_visitor would be an alternative, but clearly something like that would need a convincing profile before changing it. I see no need to use a list for the queue as we only change elements at the end. A vector or most likely a deque (apparently it changes size frequently and involves changes at the front) would be appropriate. A std::queue based on a std::deque seems possibly even more sensible. This obviously won't help much reducing ExecutableCode allocations, though it would mean at least the accounting data is less fragmented. In combination with a stack-based ExecutableCode implementation it could help a lot. bwy -- Use Gnash, the GNU Flash Player! http://www.gnu.org/software/gnash/ Benjamin Wolsey, Software Developer - http://benjaminwolsey.de
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
