taskGnash - The GNU Flash player - Tasks: task #5847, Memory profiling

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #5847: Memory profiling

Submitter:  Markus Gothe <nihilus>
Submitted:  Sat 26 Aug 2006 10:30:32 AM UTC
   
 
Should Start On:  Fri 25 Aug 2006 10:00:00 PM UTC Should be Finished on:  Wed 13 Sep 2006 10:00:00 PM UTC
Category:  None Priority:  5 - Normal
Status:  In Progress Privacy:  Public
Assigned to:  nihilus Percent Complete:  40%
Open/Closed:  Open Effort:  0.00

Thu 23 Aug 2007 08:39:47 AM UTC, comment #4: 

Any resource is either manual, RC or GC (no mix allowed).

It is likely possible to drop some RC in favor of more manual.

For definitions, many instances use them for their own services
so as long as an instance of that definition is alive we can't
drop the definition. Also, as long as the definition is instantiable (I think only if PlaceObject tags are available
pointing to it) we can't get rid of it. Usually, SWF generators
avoid to put anything in the dictionary if it's not used.

Theoretically, we could leave ownership of definitions to the
character's dictionary. Unfortunately there are execption, which
are again due to the design gap of renderers handling definitions instead of instances. The gap is that some instances have definitions which are not in a character dictionary (TextField and MovieClip created by AS, sprite_instance drawable, etc.)
For these we should analyze lifetime and find an appropriate owner. The RC model solves this discrepancy.

 Sandro Santilli <strk>
Group Member
Thu 23 Aug 2007 08:26:45 AM UTC, comment #3: 


>RC is still used for character definitions and other things.


Right. I don't mean to move definitions to GC. Is it a complex work to manage definiton resources by hand(explicit deletion)?  I don't believe we can not live without smart pointers.

> I'd keep both for now, each managing its own stuff.

OK, but the current status is that boost::intrusive_ptr is absolutely over used. It's ugly there even it does nothing when GC is enabled.

We are going to drop RC for GC managed resources(in the source code level), right:)?

 Zou Lunkai <zoulunkai>
Thu 23 Aug 2007 08:11:15 AM UTC, comment #2: 

RC is still used for character definitions and other things.
The more things are under GC the more cost would mark&sweep have.
I'd keep both for now, each managing its own stuff.

 Sandro Santilli <strk>
Group Member
Thu 23 Aug 2007 06:21:47 AM UTC, comment #1: 

As for memory profile, RC model is terrible.
GC is much better in memory cost(not sure about speed).

BTW, are we going to drop RC? I can see no help to maintain two models. Gnash is already big enough...


Zou Lunkai <zoulunkai>
Sat 26 Aug 2006 10:30:32 AM UTC, original submission:  

Profile for leaking / overuse of memory... Seem like gnash is a memory hog, eats 100MB whilst playing elvis.swf for me.

 Markus Gothe <nihilus>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by strk (Posted a comment)
  • -email is unavailable- added by zoulunkai (Posted a comment)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2006-09-14 nihilus Percent Complete20% 40%
    2006-09-14 nihilus StatusNone In Progress
    2006-08-26 nihilus Percent Complete0% 20%

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-8eb0.
    Corresponding source code