Path: utzoo!attcan!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.lang.c++ Subject: Re: Static typing and OOP efficiency Message-ID: <71618@microsoft.UUCP> Date: 1 Apr 91 19:35:36 GMT References: <1991Feb16.121825.15353@gpu.utcs.utoronto.ca> <27BFDF44.3EA6@tct.uucp> <27C523A2.2155@tct.uucp> <4679@m5.COM> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 28 In article <4679@m5.COM> tma@m5.UUCP (Tim Atkins) writes: |One thing that seems to be forgotten in such comparisons is that the comparison |should not be the ratio of d(A) to d(B) where d is dispatch speed and A and |B are languages but should instead be the ration of (f + d(A)) to (f + d(B)) |where f is the time taken for the average method execution. This of course |assumes that f is comparable in both languages which is the case when |comparing Objective C and C++ for methods that do normal C-ish things. There is no one "right" way to benchmark these speed issues. One person will argue the "right" way to compare speeds is that ratio of "average" function execution speed is "right." Another will argue that a weighted average -- biased to place more weight on functions in loops is "right." Others will argue that speed of execution is not an issue, and the only thing that matters today is the amount of time it takes a programmer to write a program. These all just represent the individual biases of programmers as to what it takes to do their own individual jobs. *My* bias is that a language shouldn't be considered "Object Oriented" if a programmer can't afford to use its "Object Oriented" features for all programming subtasks. In particular, if dispatch is so slow that for little "set/get" access functions programmers are forced to bypass encasulation and normal syntax, and revert to a secondary syntax, then I don't consider that language to support "Object Oriented" programming. Thus for me, "Object Oriented" compilers must include techniques for inlining and/or "customization". I consider such inlining or customization to be much more important than the exact details used for a full-blown method dispatch -- which is used only when a compiler can't determine a customized or inline version to avoid the full-blown dispatch overhead.