[fwd] Objective-C/C++/C tests on UNIX, results

[Theodore C. Belding]

Here's something I ran across; the beginning of the post is garbled
somehow.  The benchmarks were run using gcc 2.7.2.1 Obj C.  I know Rick
Riolo has been investigating the costs of using Obj C message passing vs. C
function calls (for instance, in calls to the random number generator) and
thought this might be of wider interest.  This isn't meant as a comment on
using ObjC vs. C or C++; it's just always good to know what's eating up the
CPU time, and what the tradeoffs are.  Has anybody figured out how to
profile a swarm app?  If I remember right, Nelson said he's done it before.
-Ted
 
>Path:
news.itd.umich.edu!newsxfer3.itd.umich.edu!howland.erols.net!news-peer.gsl.n
et!news.gsl.net!news-stock.gsl.net!news.gsl.net!news1.rad.net.id!news.sprint
link.net!news-stk-11.sprintlink.net!news.emanon.net!news.franklin.com!news
>From: address@hidden (David T. McWherter)
>Newsgroups: comp.sys.mac.programmer.codewarrior
>Subject: Objective-C/C++/C tests on UNIX, results
>Date: Thu, 2 Jan 1997 21:38:48 GMT
>Organization: Franklin Electronic Publishers, Inc. (FEP);  Burlington, NJ
>Lines: 97
>Sender: address@hidden (Usenet News Account)
>Message-ID: <address@hidden>
>Reply-To: address@hidden
>NNTP-Posting-Host: franklin.emanon.net
>X-Nntp-Posting-Host: ss5mth04
>
>        I've been spending some time learning how to program in objective-c,
>        To test the dispatch times of C, C++, and Objective-C, I got on
>
>int regular_function ( char* buff ) {
>        buff[0] = 0;
>        return 0;
>}
>
>The C++ version was similar, except that the function executed was a pure
>virtual function...created like this:
>
>class base {
>public:
>        virtual int testFunc ( char* buff ) = 0;
>};
>class sub { 
>public:
>        virtual int testFunc ( char* buff );
>};
>
>The C++ function was dispatched from both a stack-based object and a heap based
>object (dispatched through an object and a pointer to an object, respectively).
>
>The Objective-C function was also similar to the C routine, implemented
like this:
>
>@interface myclass : Object 
>{
>}
>- testFunc:(char*)buff;
>@end
>
>@implementation myclass
>- testFunc:(char*)buff
>{
>        buff[0] = 0;
>        return 0;
>}
>
>When I dispatched the Objective-C routine, I used an id identifier:
>
>        id myObjcID = [myclass alloc];
>        
>To time the routines, I used the UNIX system routine time(), which returns
>a value in seconds, since a set date (00:00:00 GMT, Jan 1, 1970).  It's not
>the most accurate measurement method, but it seems to have been suitable for
>my tests. 
>
>Each function was dispatched 0xFFFFFF times.  For those of you who don't
>have 16 fingers, and must rely upon the more common 10 fingers, that's 
>16777215 times, in a tight loop, that looked like this:
>
>for ( i = 0L; i < 0xffffff; i++ ) { 
>        /*dispatch here*/
>}
>
>Hence, I tried to keep the processor mostly busy in dispatching the routines
>in question.
>
>Enough talk...the results were quite surprising.  Here they are:
>
>        C                       10 seconds
>        C++ (stack-based)       13 seconds
>        C++ (heap-based)        18 seconds
>        Objective-C             27 seconds
>
>That's quite an impressive spread.  According to what I've read on various 
>newsgroups and on NeXT's WWW pages related to Objective-C, the performance
>of Objective-C based apps relies largely upon the efficiency of the runtime
>environment on that system.  There have been arguments stating that most 
>runtime environments that are available are not very well written, although
>there seems to be an indication that the NeXTStep environment is quite good.
>Being as I only have one system with which I can compare my results, I'd be
>rather interested in what other people might get from executing similar tests
>on their systems...especially those running NeXTStep (I wonder how many of 
>those people are here, on comp.sys.mac.programmer.codewarrior?).
>
>Curiously, in my original tests, I was following Objective-C "guidelines" 
>and I was returning "self" in the routine which I was testing, as no real
>return value was applicable.  In these tests, everything else was the same,
>and yet, the Objective-C dispatching took 42 seconds to complete...15 seconds
>longer than the runs in which a simple 0 was returned by the function.  ("self"
>is quite similar to C++'s "this" variable...)  I hope that this is a problem
>limited to my runtime environment...please?
>
>I was under the impression that by indicating to the objective-c compiler
>that I knew what kind of object I was working on, by replacing my "id"
reference
>by a pointer to an object of the class which I was testing, substantial
speed gains
>could be had.  After testing this out, I found that there was no
noticeable speed
>difference.  Perhaps using Objective-C's dynamic casting mechanism must be used
>to get these speed benefits...but I have not yet tried this mechanism (as I am
>still unfamiliar with it).
>
>I would dearly hope that my runtime environment is a horrible, bloody bit of
>code, as mine is such a simple example, that it doesn't have to worry about
>things such as hash-table lookup collisions (do these generally occur in 
>Objective-C environments?), class cache misses, etc.  
>
>-David McWherter
>address@hidden

--
Ted Belding                      <mailto:address@hidden>
University of Michigan Program for the Study of Complex Systems
<http://www-personal.engin.umich.edu/~streak/>