[MTOS-dev] Circular reference issue

[Timothy Appnel]

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

-- 
Timothy Appnel
Appnel Solutions
http://appnel.com/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: t3.pl
Url: http://www.sixapart.com/pipermail/mtos-dev/attachments/20080115/af572993/attachment-0001.pl 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t3.log
Type: application/octet-stream
Size: 260035 bytes
Desc: not available
Url : http://www.sixapart.com/pipermail/mtos-dev/attachments/20080115/af572993/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Builder.pm.probe.patch
Type: text/x-patch
Size: 62 bytes
Desc: not available
Url : http://www.sixapart.com/pipermail/mtos-dev/attachments/20080115/af572993/attachment-0001.bin