[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: Travis Griggs
Subject: Re: Objective-C and Smalltalk; speed of message send
Date: Wed, 18 Aug 2004 22:02:27 -0700

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

Hi Travis!

> Do real world examples count then?


> 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
One man's blue plane is another man's pink plane.

reply via email to

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