Re: Objective-C and Smalltalk; speed of message send

[Richard Frith-Macdonald]

On 19 Aug 2004, at 17:23, Leigh Smith wrote:

> > Maybe ... I think that most likely the main problem is using 
> > stringWithFormat:
> > That method is slow for a variety of reasons (it's probably faster 
> > now than when the smalltalk test was done),
> > not least the fact that it uses the autorelease mechanism.  
> > Autorelease is fundamentally pretty slow, and a
> > good garbage collection system would perform better.  However, 
> > retain/release/autorelease is the way
> > things are currently done.
>
> I'm surprised that automatic garbage collection would be found (or 
> perhaps is just assumed?) to be faster than reference counting.

I believe that simple reference counting is comparable with GC ... it 
looked that way when I did tests long ago.
However, I was not talking about simple reference counting, but about 
the autorelease mechanism.
Autorelease pools are thread-local, so the implementation of 
autorelease requires a system call to determine the current thread, 
which is quite expensive.

> >From my own experience developing the MusicKit and SndKit 
> (http://www.musickit.org), reference counting is preferable because it 
> gives us control of when memory is allocated and released, therefore 
> we can ensure these potentially slow operations do not occur with the 
> hard real time constraints of audio signal processing. As an example 
> we can have very efficient signal processing with preemptive 
> scheduling that ensures a single hardware buffer's latency between 
> requesting a sound be played and hearing the result - on Windows, 
> MacOS X and Linux.
>
> More importantly, it's possible to read the code and understand what 
> the hell is going on! Good design is the key (and reference counting 
> does not really compromise that design, in my experience) and the 
> dynamic OO of ObjC aids that design process. Ditto Smalltalk, I 
> certainly wouldn't mind GC, but for real-time work I'd want some 
> control over it, perhaps just hinting impending reuse. Having looked 
> at the audio code of Squeak (not recently), the higher level design is 
> great, but then the connection to the C means big design compromises 
> which miss the opportunity to propagate future design optimisations.
>
> Of course, this may just suggest we need to look deeper at autorelease 
> to see if caching of releases is possible, but I haven't looked at the 
> GNUstep code, so I don't know if that's appropriate or may already be 
> done.

I have no desire to get into a flame war about gc ... it always seems 
to go that way.
I am not a GC fanatic, and don't use it in my own code ... but it 
certainly has advantages in a lot of cases.