Re: string literals and performance
Re: string literals and performance
- Subject: Re: string literals and performance
- From: "Gary L. Wade" <email@hidden>
- Date: Sun, 25 May 2014 01:11:05 -0700
The performance benefit for choosing the first style over the second style comes in if you need to debug your app or change the contents of a string literal.
If you hard code the same string everywhere you use it, as with the second case, you are either going to copy/paste or type it all over again. If you type it, this can lead to misspellings which can be frustrating to debug especially if the string is a key or a format.
If you use a named constant like the first case, the compiler will tell you when you make a misspelling with the variable.
Similarly, if you decide to change the contents of string, a named constant improves your performance by you only changing it one place rather than having to change it in multiple places. Even a global search and replace requires some proofing to be sure you don't change too many instances.
For example, if any of these strings are localizable, using separate named constants per meaning will keep you safe when dealing with false friends. As an example of one app I worked on, we had two strings that were identical in English but different in Spanish: State as in California and State as in On/Off but Estados for the former and Condicion for the latter.
While it is true you will see little, if any, performance difference in the execution of your code, you will find your coding and debugging performance improved by doing these safer and best practices of software development.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/
> On May 24, 2014, at 9:08 PM, 2551 <email@hidden> wrote:
>
> Are there any performance implications that would suggest preferring one or the other of these different styles?
>
> NSString *s = @"sing me a song";
> [myClass aMethod: s];
>
> and
>
> [myClass aMethod: @"sing me a song"];
_______________________________________________
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