[MTOS-dev] Circular reference issue

[Byrne Reese]

You are right we do. Consider this an official IOU from Six Apart. :)


On 1/15/08 7:56 PM, "Timothy Appnel" <tim at appnel.com> wrote:

> Someone at Six Apart is going to owe Hirotaka and I several adult
> beverages of our choice.
> 
> I picked up where Hirotaka left off looking for why so many
> MT::Template::Node objects are left at the end of a page build. After
> several hours I should have been spending on other work I made an
> interesting discovery though I'm not 100% sure what it means.
> 
> I need to stop here and will be tied up most of the day tomorrow that
> I thought I'd better report what I've found in the hope it helps the
> next person figure out where to look next.
> 
> After apply Hirotaka's patches to the release 1240 (current dev
> release when I started), I began experimenting with DESTROY methods
> that traversed the tree calling the DESTROY method on its children
> before blanking its own internal memory. Nothing I did cleared up
> those nodes that were hanging out. I even inserted debugging messages
> that showed that these DESTROY methods where getting called. The still
> persisted.
> 
> This led me to wonder if nodes where being created without a parent
> relationship or where the node had a parent, but the parent had
> disowned the child. Parsing the default main index yielded 47 nodes
> that did not have a parent defined. In a quick glance of the data dump
> most, but not all, of these nodes had children.
> 
> So my theory is that some of these nodes that are collecting is
> because whole branches are somehow being disowned from their roots
> with circular references still entact. I'm not 100% sure that is
> correct though, but that is my hunch at the moment.
> 
> The nodes without children are what puzzle me at the moment. Why
> aren't those falling out of scope? I'm using weakened references to
> build my tables and know that some references I stored there are
> undefined by the time I run the dump.
> 
> Another curious thing I noticed is that a lot of the parent-less nodes
> with children are the If tag. Perhaps its something in how conditional
> branch tokens are being managed?
> 
> I've attached a test script and a patch to MT::Builder that has the
> debugging code needed to collect nodes being created. I also attached
> a log of the last run I did with all the gory details exposed.
> 
> This has been really tricky because the compile code is just plain
> nasty. I really have to wonder if it really needs to be that way. I
> just find it hard to believe this couldn't be a lot better organized.
> 
> Having nodes being "psuedo objects" without a constructor or methods
> for accessing its parent, children and attributes, really makes
> debugging this sort of thing so much harder since their creation is
> all over the place. It also gets very confusing trying to read through
> the code and pick out where a parent is getting set (array index 5) or
> children are being fetched (array index 2). I recognize that perl
> method calls are slow in comparison to accessing references directly,
> but does it really make THAT big a difference to the system's overall
> performance to lay such a heavy burden on code maintainability?
> Compiling a template seems small in comparison to other operations
> like building the page. I'm just wondering outloud here. It just seems
> a shame that this DOM interface was created and yet the system doesn't
> actually use it.
> 
> Hope this was helpful. Carry on.
> 
> <tim/>