The subclass approach prevents the need to keep a record of the node type for the vast majority on nodes.
I no longer have clear data on how much that helped for memory, but I think it helped somewhat. Feel free to do more investigation into that. I don’t think subclassing effects language conformity. Am I wrong? Where subclassing helps is that the browser tools group instances by class, so this way, you get (most of) elements, text and attributes grouped separately. Thanks, Harbs > On Dec 10, 2019, at 11:56 PM, Greg Dove <[email protected]> wrote: > > That does sound like a great improvement, Harbs. Congrats on the massive > memory improvements! > > If the 'subclass' approach for attributes and text was not the main basis > for achieving the improvements, do you consider that we can avoid those > subclasses and restore the more conforming actionscript 3 implementation? > > If that change with subclasses was for ease of debugging only, then I'd be > keen to find better ways to make debugging easier as I mentioned elsewhere, > keeping language conformance for what is a core as3 type, and therefore > keeping the best chance of what we have working with all legacy code. > > > > > > > On Wed, Dec 11, 2019 at 1:55 AM Harbs <[email protected]> wrote: > >> One thing to keep in mind with XML: >> >> If you keep even a single node (element or attribute) in memory, that will >> retain your entire tree. >> >> Make sure you use copy() (or setParent(null)) to get rid of parent >> references for leaf nodes that might be kept. >> >> HTH, >> Harbs >> >>> On Dec 10, 2019, at 1:14 PM, Piotr Zarzycki <[email protected]> >> wrote: >>> >>> Hi Harbs, >>> >>> Great work! We are using in our app XML - didn't check earlier memory >>> consumption, but it looks like really good improvement. >>> >>> Thanks, >>> Piotr >>> >>> wt., 10 gru 2019 o 11:04 Harbs <[email protected]> napisał(a): >>> >>>> I just added code like this to the constructor: >>>> >>>> if(!_class_initialized) >>>> { >>>> Object.defineProperty(XML.prototype,"0", >>>> { >>>> "get": function():XML{return this as >> XML}, >>>> "set": function():void{}, >>>> enumerable: true, >>>> configurable: true >>>> } >>>> ); >>>> _class_initialized = true; >>>> } >>>> >>>> where _class_initialized is a static boolean. >>>> >>>> This sliced the memory requirements for XML instances in roughly half! >>>> >>>> Not totally thrilled with the conditional code in the constructor, but I >>>> don’t have any better ideas at the moment. >>>> >>>> Between the improvements I’ve made to XML and aggressive work on >> removing >>>> extraneous object references (particularly XML), I’ve reduced the memory >>>> footprint of my app for a particularly complex document from about 155MB >>>> down to 103MB. >>>> >>>> The memory impact of using XML went from about 75MB down to 22MB. >> (That’s >>>> for well over 100,000 nodes kept in memory.) >>>> >>>> Not bad for a few days work… ;-) >>>> >>>> Harbs >>>> >>>>> On Dec 9, 2019, at 7:19 PM, Greg Dove <[email protected]> wrote: >>>>> >>>>> btw I am still happy to look into the possibility of doing a first time >>>>> 'get' access for the Class itself on its package that runs static code, >>>> but >>>>> as Alex pointed out, it could have issues with the minified version, so >>>> it >>>>> is more at 'investigate' rather than 'solution' stage. I have not >>>>> prioritized this for now... >>>>> >>>>> >>>>> On Tue, Dec 10, 2019 at 6:13 AM Greg Dove <[email protected]> wrote: >>>>> >>>>>> This might be a good candidate for getting the static initialization >>>> code >>>>>> block working (it is currently not in js). >>>>>> >>>>>> We discussed that recently in another thread. >>>>>> >>>>>> public class MyClass{ >>>>>> >>>>>> {//static init block >>>>>> COMPILE::JS{ >>>>>> Object.defineProperty(MyClass.prototype,"0", >>>>>> { >>>>>> "get": function(){return this}, >>>>>> "set": function(){}, >>>>>> enumerable: true, >>>>>> configurable: true >>>>>> } >>>>>> ); >>>>>> } >>>>>> } >>>>>> >>>>>> public function MyClass (){ >>>>>> >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> On Tue, Dec 10, 2019 at 6:00 AM Alex Harui <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Did you try: >>>>>>> >>>>>>> function get 0():XML { return this; } >>>>>>> function set 0(value:XML) {} >>>>>>> >>>>>>> Within a COMPILE::JS, I think the variables: >>>>>>> >>>>>>> this["constructor"] >>>>>>> this["__proto__"] >>>>>>> >>>>>>> are available. >>>>>>> >>>>>>> HTH, >>>>>>> -Alex >>>>>>> >>>>>>> On 12/9/19, 8:27 AM, "Harbs" <[email protected]> wrote: >>>>>>> >>>>>>> In my question to minimize memory requirements in XML, I’d like to >>>>>>> optimize the zero index accessor. >>>>>>> >>>>>>> Right now, we have Object.defineProperty in the XML constructor. >> The >>>>>>> byproduct of that is we have a function defined on every single >>>> instance of >>>>>>> XML. Ideally that should be on the prototype object. This should >>>>>>> drastically reduce the memory requirements for instantiating XML. >>>>>>> >>>>>>> In JS, that’s pretty easy to do: >>>>>>> >>>>>>> Object.defineProperty(thePrototype,"0", >>>>>>> { >>>>>>> "get": function(){return this}, >>>>>>> "set": function(){}, >>>>>>> enumerable: true, >>>>>>> configurable: true >>>>>>> } >>>>>>> ); >>>>>>> >>>>>>> I’m struggling with how to do it in AS3. How can we get a reference >>>>>>> to the prototype outside the constructor or have the compiler >> construct >>>>>>> this kind of function automatically? >>>>>>> >>>>>>> Thoughts? >>>>>>> Harbs >>>>>>> >>>>>>> >>>> >>>> >>> >>> -- >>> >>> Piotr Zarzycki >>> >>> Patreon: *https://www.patreon.com/piotrzarzycki >>> <https://www.patreon.com/piotrzarzycki>* >> >>
