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

[Travis Griggs]

On Aug 18, 2004, at 12:49, Marcel Weiher wrote:

> Hi Travis!
>
> > Do real world examples count then?
>
> Always!
>
> > For a while we've considered porting a straight C processing
>  > application upward into Objective-C. One of the things we wanted to 
> do
> > was use a Dictionary (NSMutableDictionary) to store arbitrarily keyed
> > tallies. This would replace an existing 2D array in strict C.
>
> Whoa, an NSDictionary is a pretty heavy-weight item, especially
>  compared to a simple 2D array!  Why not stick with the 2D array, if I
> may ask?  After all, one of the point of Objective-C is that it *is* C.

The problem was that the 2D array was conceived when the application 
was simple. There were N attributes with M counts per attributes. So, 
the simplest thing that could possibly work, was a 2D array. But 
applications have ways of growing more and more versatile and more 
complex. The N x M assumption broke down a LONG time ago, but 
developers just kept hacking it (e.g. we'll pretend this one cell means 
this). If one were to model it today, it's become an arbitrarily keyed 
dictionary of tallies. But there's a large installed library base, so 
we want something that still encode the m,n lookups, but allow us to go 
forward. And we need to be able to reflect on it (e.g. tell us what 
keys you've got stored right now). Is there an intermediate weight item 
that falls between indexed storage, and keyed storage?

> >  We decided to use NSStrings as the keys.
>
> Also potentially fairly heavy, though a common choice.  I remember
>  people complaining about NSString's performance compared to char* when
> Foundation was introduced.  However, NSString is really for "human
> readable" text, whereas char* is often more for "tokens", or really
> just byte-sequences.

Well, the problem is, you can't use char*'s as Dictionary keys. You 
need an object. I guess we could roll our own lightweight string object 
for use as a key. Then we'd have to manage all of the char* life cycle 
ourselves.

> >  To maintain a backwards bridge, we took the old 2D access indices 
> and
> > turned them into a string. And then stored/set them in the
> > NSMutableDictionary via those. The performance was not impressive.
> I wouldn't expect it to be.  NS(Mutable)Dictionary is pretty slow.  One
> issue is that it copies its keys.  Arrrggghh.
>
> >  I got some pointers from this mailing list, which improved things.
>
> What were the suggestions?

We were using the NString stringWithFormat (or something like that). 
Switching to using sprintf, and then NString stringFromCString. There 
were also some tuning of when to release the auto release pools.

> >  In the end, we'd squeezed out a solution which was almost 50% of the
> > speed what VisualWorks Smalltalk did the same task in. The Smalltalk
>  > one was still 2x faster though, i never had to think about the 
> memory
> > management issues, and it worked the first time.
>
> No complaints about Smalltalk from me :-))

I know. :)

>  > That aside, I'm still a huge Objective-C fan, and we may still go 
> that
> > route anyway. We're not sure how to get our semi-realtime data
> > into/outof the Smalltalk memory model fast enough. :)
>
> Yep, the really great thing about Objective-C is its connectivity.

Yep. And it's simplicity. And dynamism. Etc. I think the weakest part 
is the community/industry lack of anything more than primitive 
reference counting for a GC solution (yes, I know about the Boehm-GC 
stuff, I just don't see it used or embraced at all).

--
Travis Griggs
Objologist
One man's blue plane is another man's pink plane.