On the testcase in the URL field, about 20% of the total time is spent on creation of XPCWrappedNative objects. The problem is that the page doesn't hold on to the JSObjects, and touches a lot of nodes, so we end up GCing (probably offa branch callback) and by the time the code comes back to the first table cell we've already GCed its XPCWrappedNative. The question is what to do about it. The two things I've thought of so far are: 1) "Preserve" all node XPCWrappedNatives, not just those that have expando props set. The drawbacks here are that it doesn't work for XPCWrappedNatives in general and that it keeps the XPCWrappedNatives alive for the lifetime of the document if the nodes are in the document. 2) Only GC an XPCWrappedNative if it hasn't been touched for more than some threshold time (say 10 seconds?). The drawback here is that we'd need another member in XPCWrappedNative and some extra code to deal with this. Any other thoughts? Assuming we care to make this better at all, of course...

(In reply to comment #0) > 1) "Preserve" all node XPCWrappedNatives, not just those that have expando > props set. The drawbacks here are that it doesn't work for XPCWrappedNatives in > general and that it keeps the XPCWrappedNatives alive for the lifetime of the > document if the nodes are in the document. (1) is the one true way. RAM is cheap, we're not going to break memory budgets with this fix. My premise is that XPCNativeWrapper must be transparent, which means cheap to use again, which in part implies "not ephemeral" -- but transparency also means same object identity over time, which also implies "not ephemeral". /be

> (1) is the one true way. RAM is cheap, we're not going to break memory budgets > with this fix. (1) means that a DOM constructed via DOM manipulation will start and stay a good bit bigger than a DOM constructed via the parser. And again, it only works for nodes.. Note that this is XPCWrappedNative we're talking about, _not_ XPCNativeWrapper. Also note that we do currently have object identity in the only way that matters (that is, it's impossible to detect when the XPCWrappedNative changes, since we make it stick around as soon as you actually set any props on it).

Oops, I typed XPCNativeWrapper (dammit) but meant XPCWrappedNative. If we have identity preservation, then I'm down to perf, that is, to this bug. Lack of perf symmetry and absolute goodness can kill transparency -- just lack of symmetry or smoothness can do it. /be

So I guess the question is whether we need a solution that works for more than just nodes...

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.