Re: NSMapTable with C strings as keys
Re: NSMapTable with C strings as keys
- Subject: Re: NSMapTable with C strings as keys
- From: Oleg Krupnov <email@hidden>
- Date: Wed, 29 May 2013 07:14:51 +0300
> Why not just create NSString wrappers? By using the -initWithBytesNoCopy:length:encoding:freeWhenDone: method you can avoid it copying the actual C string characters, it literally just becomes a thin wrapper.
In my case it's more about extra calls than extra memory but thanks! Didn't know about this.
> For the sake of avoiding something you *assume* to be slow, or inefficient, you've taken the discussion in a direction that is vastly more complicated.
The code in question is frequently used in many places so I think it's worth optimization.
This KISS school of thought has brought Microsoft to building the slow and inefficient .NET technology, and it's had a hard time persuading everybody and his dog that hardware is evolving faster than they right inefficient code, so it was "ok", but ultimately this approach failed.
While I generally agree that premature optimization is evil, I do not understand why I cannot or shouldn't always keep in mind the cost of things I am using, and consider more efficient approaches, especially when they are simple. (This time it has turned out not simple and not even efficient, so I changed my mind).
The profiler is not a panacea; when you have hundreds of small, not-so-efficient pieces of code like this, all you see in profiler is a long list of small consumers, totaling in heavy use of objc runtime calls.
On May 29, 2013, at 1:46 AM, Graham Cox <email@hidden> wrote:
>
> On 28/05/2013, at 3:46 PM, Oleg Krupnov <email@hidden> wrote:
>
>> I'd like to have a dictionary using C strings as keys (because I
>> already have const char* strings and would like to spare on creating
>> NSString wrappers)
>
>
>
>
> K.I.S.S.! If you can prove this approach is a problem by actual profiling, then OK, then you can talk about a more complex solution.
>
>
> --Graham
>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden