[comp.sys.mac.programmer] Static vs Dynamic Binding

lsr@Apple.COM (Larry Rosenstein) (09/02/89)

In article <9389@cadnetix.COM> pem@cadnetix.COM (Paul Meyer) writes:

> so not allowing static binding doesn't lose any functionality.  It DOES, 
how-
> ever, lose efficiency in the case where static binding would be 
sufficient.

In MPW Object Pascal, the linker can optimize some method calls and change 
them to use static binding.  In theory, and particular call for which the 
linker can determine the target method can be optimized to be a direct JSR 
(no runtime dispatching).  In practice this happens for methods that are 
not overridden at all.  (It is clear in those cases what the target method 
it.)

In a class library, you tend to define method just in case someone needs 
to override them, but most clients do not override every method.  
Therefore this optimization turns out to be a big win.  (You still have 
the overhead of a class ID in each object, but the method tables will be 
removed if possible.)

In C++ the programmer can choose between static and dynamic binding.  This 
gives you more control, but also means the programmer has to trade off 
flexibility for performance.  It is often hard to know whether a 
particular method might ever need to be overridden.  

> by putting a pointer to a table of function addresses in the object, 
with a
> separate table for each type, and dereferencing into it to make member 
function
> calls.  

C++ uses this scheme for its dispatching.  A method ID is an index into 
the table, so the dispatching takes constant time.

Object Pascal produces 1 table for each method, listing all implementors 
of the method.  The dispatcher does a linear search through the table, 
which is usually very short.  Object Pascal also caches the results of the 
last look up.  If you call the same method with the same kind of object, 
the second dispatch is twice as fast.  The method dispatcher typically 
adds 50-60 microseconds of overhead on a MacPlus.  (Although I'm reciting 
those figures from memory.)

Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1