[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Richard Frith-Macdonald
Subject: Re: Objective-C and Smalltalk; speed of message send
Date: Thu, 19 Aug 2004 17:45:26 +0100

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]