Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!johnson
From: johnson@m.cs.uiuc.edu
Newsgroups: comp.object
Subject: Re: What is Objective C?
Message-ID: <77500056@m.cs.uiuc.edu>
Date: 4 Sep 90 22:36:00 GMT
References: <3864@bingvaxu.cc.binghamton.edu>
Lines: 22
Nf-ID: #R:bingvaxu.cc.binghamton.edu:3864:m.cs.uiuc.edu:77500056:000:1116
Nf-From: m.cs.uiuc.edu!johnson    Sep  4 17:36:00 1990


>So . . . will a program that, by the language definition, must do
>garbage collection, run as quickly as a program where the "user" (the
>programmer in the language in question) must manage memory?  Probably
>not, unless the language implementor has done a terrific job, and the
>"user" has botched it.

Although I agreed with most of what Paul Chisholm said, I disagree
with this statement.  My experience with C++ is that memory management
takes a lot of CPU time.  We use reference counting, and have to lock
objects before changing their reference count (we are using a
multiprocessor).  Not only is this time-consuming for the programmer
to get right, it is time-consuming for the computer to execute.

Because programmer-controlled memory management is all tied up
with the application program, it is very hard to tell exactly how
much time is spent in it.  Thus, programmers don't know how much
time their code spends in memory management.  I would be quite
surprised if an optimizing compiler that understood memory management
couldn't do better.

Ralph Johnson - University of Illinois at Urbana-Champaign