Performance penalty from inheritance - Forum - OpenEdge Development - Progress Community

Performance penalty from inheritance

 Forum

Performance penalty from inheritance

  • Your measurements don't include running the destructors (I know you don't

    have any, but you could have done) which is another bit of additional

    overhead.

    When you inherit, you can have 30,000 destructors. Without inheritance, you

    have 10,000 destructors.

    There are a variety of optimisations (oo related and otherwise) that could

    be implemented and we are working on some of them.

    --

    regards,

    gus bjorklund, progress software

    If we wish to count lines of code, we should not regard them as lines

    produced but as lines spent. (Edsger Dijkstra)

  • So, yes, appropriate parameters speeds up the whole process, but the contrast between the inherited version and the non-inherited version is still there and nearly as substantial.

    My point is that there is only one object being instantiated in each case ... or, should be only one.  The inheritance should be resolved at compile time into a single resulting object.  In this case, the instantiate objects should be identical.  So, why is one taking 2-3 times longer?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • So, we know we can't blame it on empty constructors ... except that logically there is a constructor whether it is empty or not.  But, having this have a performance impact is only sensible if the AVM is constructing 30000 objects instead of 10,000.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Yipe.  So you really are instantiating 30,000 objects in the second case.  Ouch.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I told you --- after the object itself is created, the constructors are run

    for each class in the hierarchy.

    While the code for the constructors could, in theory, be elided into a

    single constructor at your leaf level, in fact they are not.

    Furthermore, if you do not write a constructor, a default constructor which

    calls the superclass constructor is generated in the r-code. We are going to

    eliminate that.

    --

    regards,

    gus bjorklund, progress software

    If we wish to count lines of code, we should not regard them as lines

    produced but as lines spent. (Edsger Dijkstra)

  • So, we know we can't blame it on empty constructors ... except that logically

    how do you know that?

    there is a constructor whether it is empty or not.  But, having this have a

    performance impact is only sensible if the AVM is constructing 30000 objects

    instead of 10,000.

    No, there aren't 30,000 objects.

    --

    regards,

    gus bjorklund, progress software

    If we wish to count lines of code, we should not regard them as lines

    produced but as lines spent. (Edsger Dijkstra)

  • No, there aren't 30,000 objects.

    Doesn't Shelley's explanation contradict this?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • schase wrote:

    As far as runtime class instantiation, each class is run, the setup block is run (like block 0 for procedures) and then the contrsuctor is run which must immediatelty instatiation the super class and the same happens up the hierarchy. This is necessary with strong-typing. As I said we are looking at ways to improve this like maybe keep pools of object instances for reuse, etc.

    Let me know any suggestions/comments you might have.

    Is the AVM engaging in all the overhead that goes with a normal RUN statement when it's running a constructor?

  • Yes, the Language team is investigating changes to improve performance of class instantiation.  This is part of an ongoing effort.  For example, Gus noted in this thread, that we are looking at making improvements to class instantiation when the application does not provide a default constructor.

    Evan Bleicher

    Sr. Development Manager

    Progress Software

  • No, there aren't 30,000 objects.

    Doesn't Shelley's explanation contradict this?

    I see nothing in Shelley's explanation that contradicts this. Nor anything

    that supports it.

    Either way, there are 30,000 constructors to be executed.

    --

    regards,

    gus bjorklund, progress software

    If we wish to count lines of code, we should not regard them as lines

    produced but as lines spent. (Edsger Dijkstra)

  • gus wrote:

    Either way, there are 30,000 constructors to be executed.

    And imagine what would happen if 30% of those class instances had a TT definition. 

  • bleicher wrote:

    Yes, the Language team is investigating changes to improve performance of class instantiation.  This is part of an ongoing effort.  For example, Gus noted in this thread, that we are looking at making improvements to class instantiation when the application does not provide a default constructor.

    Doesn't the AVM know that the target's an object instance?

  • And imagine what would happen if 30% of those class instances had a TT definition. 

    With or without REFERENCE-ONLY

  • That being said it was a design decision with OO to keep each class  as a separate r-code file.

    I take this to mean that if there is a class hierarchy in which the superclasses are compilable, i.e., not abstract, that there would be a separate r code file for each.  I don't have a problem with that, even though good OO suggests that one should never be instantiating one of those superclasses on its own.

    So  at compile time we look at the hierarchy and set up our dispatch table  as appropriate and we keep a "digest" value for each r-code used.

    Three classes per used, three digest values.  No?

    As far as  runtime class instantiation, each class is run, the setup block is run  (like block 0 for procedures) and then the contrsuctor is run which must  immediatelty instatiation the super class and the same happens up the  hierarchy.

    So, this seems to indicate that all classes in the hierarchy are going to be instantiated.  That seems to point to 30,000 classes to me.

    This certainly would be a strong disincentive for those people who like to stick superclasses over the top of everything "just in case".

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I don't have a problem with that, even though good OO suggests that one should never be instantiating one of those superclasses on its own.

    Thomas, for the sake of understanding what's going on in the runtime, wouldn't it be wise to keep lectures about good OO design beside for now. If the super class is abstract or not is probably irrelevant right now because the abstract base class can also have constructors.