'I don’t think subclassing effects language conformity. Am I wrong?'
I guess it depends what each of us thinks of as 'language'. Because XML is
an as3 core type, I think of it as part of language. Another way to think
of it is whether or not it would work the same in AVMPlus (which is
'bare-bones' as3 types, and which I use for testing sometimes locally).
The change can certainly break certain patterns that may have been used.
One of them I can think of is not that unusual, such as:
switch(obj.constructor) {
case XML:
break;
case SomethingElse:
break;
}
The above would potentially no longer work the same.
It's more the case that if something can work the same, I feel like it
should, to keep things as consistent and reliable as possible. That
certainly is what clients are telling me they are looking for when porting
a legacy app, and it is one of the biggest credibility challenges that
Royale has to address in terms of gaining acceptance with a new user :
'Does it really work the same?'
We often say that for porting to Royale, the business logic should remain
the same and the majority of the work is in the views. I don't know how
many you've worked on, but I've worked on 4 large codebases now. If I
reflect on the past year, the majority of my effort and biggest issues were
actually with problems related to business logic, probably AMF related with
Carlos and XML for another recent client. The view stuff has been
relatively easy (there absolutely are things to improve in this area still,
but the problems have been 'minor' by comparison). So please forgive me if
I tend to be a little resistant to anything that might make business logic
stuff work less often than it otherwise could, I am only focusing on what I
think is best for Royale.
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
Did you try the dev tools enhancement that I posted elsewhere? I'm pretty
sure that objective can be achieved without any changes to the Royale
classes, and you can even have color coding for the different XML nodeKinds
etc. I think we could probably do that support for any _ROYALE_CLASS_INFO
instance providing custom inspection or even separation of private members
from public etc to avoid visual clutter in the browser tools. At least I
know it can be done in Chrome. I think it might be supported in some other
browsers, but did not try that yet. We could probably make debugging/dev
support a whole lot nicer in general with external stuff like this.
On Wed, Dec 11, 2019 at 11:17 AM Harbs <harbs.li...@gmail.com> wrote:
> 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 <greg.d...@gmail.com> 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 <harbs.li...@gmail.com> 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 <piotrzarzyck...@gmail.com
> >
> >> 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 <harbs.li...@gmail.com> 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 <greg.d...@gmail.com> 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 <greg.d...@gmail.com>
> 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 <aha...@adobe.com.invalid
> >
> >>>>>> 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" <harbs.li...@gmail.com> 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>*
> >>
> >>
>
>
