[Top][All Lists]

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

Re: [Gnash-dev] Gnash memory allocation statistics

From: Benjamin Wolsey
Subject: Re: [Gnash-dev] Gnash memory allocation statistics
Date: Wed, 16 Dec 2009 07:46:07 +0100

> The main culprit for 16-byte allocations seems to be:
> CPU     ID                    FUNCTION:NAME
>   0  69953                     malloc:entry 
>     `malloc
>     `void*operator new(unsigned)+0x38
>     `void
> gnash::DisplayObject::queueEvent(const gnash::event_id&,int)+0x35
>     `void gnash::MovieClip::advance()+0xfc
>     `void
> gnash::movie_root::advanceLiveChar(boost::intrusive_ptr<gnash::DisplayObject>)+0x72
>     `__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
>     `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.


Use Gnash, the GNU Flash Player!

Benjamin Wolsey, Software Developer -

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

reply via email to

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