Thanks for clearing that up Mars. I don't think I could have asked for a clearer answer.
Are there any particular compiler optimisations you know of that in your opinion would have a big effect on future RB apps performance ? ( a leading question I know...;) ) On 14/1/07 18:03, "Mars Saxman" <[EMAIL PROTECTED]> wrote: > > On Jan 14, 2007, at 6:47 AM, Daniel Stenning wrote: > >> In the new RB scheme - is it ONLY RB framework objects that now all >> have >> virtual methods for every method , or do also methods on OUR RB >> code also >> all get compiled/linked as virtual all the time - EVEN in methods >> are never >> overridden ? > > There are two different concepts here. > > The RB langauge defines methods to work in a certain way: you can > "override" an inherited method with a subclass method having the same > signature. We call this a "virtual" method scheme because that's the > term used for this behavior in C++. In C++, however, "virtual" is an > option; in RB, it's just part of the way all methods work. > > There used to be a bug such that methods from the RB framework > library could not be overridden properly. This was hard to fix and > persisted for a long time. The switch from 5.5 to 2005r1 gave us a > chance to address the architectural problem that caused this issue. > In 2005r1 and later, all methods, no matter where they were defined, > respond in exactly the same way to overriding subclass methods. > > The second thing you're talking about is a specific performance > optimization known as "call devirtualization". This is where the > compiler observes that a specific call target could not have been > overridden and uses that knowledge to generate a simpler call > sequence. The method, conceptually, is still virtual, since it > *could* be overridden; the compiler just takes advantage of its > knowledge about the structure of the program to generate less complex > code that will do the same job. > > Generally speaking, RB does not have an optimizing compiler, and call > devirtualization is no exception. It is an interesting and somewhat > unusual optimization, since it relies on a type of whole-program > analysis, but it is by no means the first thing I would pursue in an > optimization system for RB. Its value is mostly in enabling other > optimizations to work more efficiently. > > Mars Saxman > REAL Software > _______________________________________________ > Unsubscribe or switch delivery mode: > <http://www.realsoftware.com/support/listmanager/> > > Search the archives of this list here: > <http://support.realsoftware.com/listarchives/lists.html> > _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
