Thread safety/freindlyness vs. performance (Was: Modest string handling optimisations)

[David Ayers]

Richard Frith-Macdonald wrote:

> On 26 Aug 2004, at 01:01, Alexander Malmberg wrote:
> 
> 
>>> - (NSString*) lowercaseString
>>>...
>>>+  if (start.length == 0)
>>>+    {
>>>+      return self;
>>>+    }
>>
>>This should be "return [[self copy] autorelease];". The current code  
>>gets the lifetime of the returned string wrong; consider:
>>
>>{
>>  NSString *foo=[[NSString alloc] init...]; /* do some string  
>>manipulation */
>>  NSString *returnValue=[foo lowercaseString];
>>  [foo release];
>>  return returnValue;
>>}

I agree that the above code is broken.

...
> It's not unreasonable to argue that it's more user-friendly/convenient  
> to retain/autorelease all values returned by all methods as standard,  
> but it's not as efficient, and it's not general behavior.
> 
...
>>It also fails if the string is mutable. There are some other cases of  
>>this in NSString that I've been meaning to fix for a while.
...
> Good point .. I consider this as more of a problem (since the memory  
> management policy issue is documented and keeps getting discussed on  
> mailing lists etc).  I guess, while it's not technically wrong to  
> return a mutable object where a method is declared as the immutable  
> version (and lots of MacOSX stuff does it), its more confusing.

...
Yes, this should be fixed.  If the "original" mutable string is altered
/after/ the call to -lowercaseString, this must not have an effect on
the string returned by -lowercaseString.

> The issue with string methods is ... performance.  NSStrings are  
> already pretty inefficient.  To what extent should we further  
> compromise performance by ensuring that method behaviors are not just  
> 'correct' (ie conform to documentation), but also avoid these oddities  
> with the validity/lifetimes of objects in an attempt to make it easier  
> for people to write reliable code with a less full understanding of  
> lifetime issues?  Perhaps we should just say ease of use is more  
> important than performance.
> 
> Also, arguably the apple guidelines are wrong ... in a multithreaded  
> environment, even if you retain/copy immediately after receiving a  
> returned value, another thread could have destroyed it.  So it's not  
> enough to say that you should retain/copy objects immediately, and the  
> only 100% safe policy is for any method returning an object to return  
> it retained and autoreleased.  However, as most classes do not claim to  
> be thread-safe, this is perhaps not an issue.

Well I'm a bit undecided about this.  Mutltithreaded apps sharing
transient strings/arrays/dictionaries can get very complicated.  I'd say
 that *if* we add retain/autoreleased policy, we add it in an
overridable macro.  Actually I'm currently considering doing something
like this for gdl2 and gsweb which currently prefer autorelease by policy.

Cheers,
David