And run the thing under Instruments, which would undoubtedly have shown memory
usage spiking even with modest data sets.
— F
On 14 Mar 2013, at 5:40 AM, Jean-Daniel Dupas <devli...@shadowlab.org> wrote:
> Le 14 mars 2013 à 11:12, Richard Heard <heard...@gmail.com> a écrit :
>
>> Your logic is clearly flawed. This only seems to replace occurrences of $
>> with the word DOLLAR.
>>
>> Also, if you are dealing with large strings, you could always use one of the
>> below idioms to reduce memory pressure.
>>
>>
>> @autoreleasepool { }
>> or
>>
>> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>> [pool drain];
>>
>> -R
>>
>
> Or simply work on a mutable string when you plan to mutate it.
>
>> On 13/03/2013, at 3:07:30 AM, Dave <d...@looktowindward.com> wrote:
>>
>>>
>>> On 13 Mar 2013, at 09:24, Markus Spoettl wrote:
>>>
>>>> On 3/13/13 9:36 AM, Dave wrote:
>>>>>
>>>>> On 12 Mar 2013, at 21:34, Graham Cox wrote:
>>>>>
>>>>>>
>>>>>> On 13/03/2013, at 6:53 AM, Dave <d...@looktowindward.com> wrote:
>>>>>>
>>>>>>> If that is the case, then how do you signal to the compiler/analyzer
>>>>>>> that you
>>>>>>> are returning a retained object?
>>>>>>
>>>>>> In general you shouldn't return a retained object (unless it's
>>>>>> temporarily
>>>>>> retained and will be autoreleased of course)
>>>>>
>>>>> Why? Where does it say this?
>>>>
>>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
>>>>
>>>>> And Autorelease is evil and should never be used if it can be avoided!
>>>>
>>>> Nonsense.
>>>>
>>>
>>> Obviously, it isn't evil, but from experience of working on 5 or more major
>>> iOS applications, I've found most bugs were caused as a consequence of
>>> autorelease, that's why I avoid it if possible. I don't have a problem with
>>> memory management, it's simple as long as you follow the rules.
>>>
>>> Avoiding autorelease makes it run faster anyway and makes the whole app
>>> more robust in general. Autorelease in the wrong hands can cause massive
>>> inefficiencies that you'd never code otherwise, here are some examples of
>>> what I mean:
>>>
>>> -(NSString*) processString:(NSString*) theString
>>> {
>>> NSString* myWorkString;
>>>
>>> myWorkString = [theString stringByReplacingOccurencesOfSting:@"/b"
>>> with:@"BOLD"]; //1
>>> myWorkString = [theString stringByReplacingOccurencesOfSting:@"/i"
>>> with:@"ITALICS"]; //2
>>> myWorkString = [theString stringByReplacingOccurencesOfSting:@"/u"
>>> with:@"UNDERLINE"]; //3
>>> myWorkString = [theString stringByReplacingOccurencesOfSting:@"*"
>>> with:@"ASTERISK"]; //4
>>> myWorkString = [theString stringByReplacingOccurencesOfSting:@"&"
>>> with:@"AMPERSAND"]; //5
>>> myWorkString = [theString stringByReplacingOccurencesOfSting:@"$"
>>> with:@"DOLLAR"]; //6
>>>
>>> and so on................
>>>
>>> return myWorkString;
>>> }
>>>
>>> This code creates 5 strings that are not needed and will clog up memory
>>> until the runloop is called or the pool is drained. Imagine there were 30
>>> such replacements going on and the initial theString is large (> 100K) and
>>> there are 100's of these strings.
>>>
>>> You don't need a degree in applied meta physics to see where this is going.
>>> It's not the fault of autorelease I know, it's the fault on inexperienced
>>> developers or people that blindly follow rules.
>>>
>>> The underlying problem is that it makes the above method data dependent
>>> without really drawing much attention to this fact. I actually had a bug
>>> that was caused by this. I worked on an iPad app for an International
>>> Newspaper. The App was working ok, until one day it crashed a 5 AM when the
>>> new edition was published and the iPad client software downloaded and
>>> processed it. When it got to the sports section a method similar to the
>>> above (although a lot more complex with a LOT more autorealsed objects)
>>> crashed. I got in a 6 AM and it took me a good while to figure out what was
>>> wrong. On that particular day, the paper published the football (soccer)
>>> league tables for the whole of the UK. Apart from there being a loads of
>>> data, it was also heavily attrubuted, bold, italics, colours etc. Well it
>>> was too much for the method and when it had built up around 80 to 100 MB of
>>> useless autoreleased strings, it crashed!!
>>>
>>> There are loads of other problems I come across as a side effect of junior
>>> (and sometimes senior) developers using autorelease, but I think the above
>>> described above was the worst.
>>>
>>> That's why I say it's "evil" and I avoid it with a vengeance. So why do you
>>> think it's a force for good?
>>>
>>> Besides all this, is it really so hard to add:
>>>
>>> [xxxx release];
>>>
>>> It's less typing than autorelease anyway!!!
>>>
>>> All the Best
>>> Dave
>>>
>>>
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>
>>> 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:
>>> https://lists.apple.com/mailman/options/cocoa-dev/heardrwt%40gmail.com
>>>
>>> This email sent to heard...@gmail.com
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org
>>
>> This email sent to devli...@shadowlab.org
>
> -- Jean-Daniel
>
>
>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/fritza%40manoverboard.org
>
> This email sent to fri...@manoverboard.org
--
Fritz Anderson
Xcode 4 Unleashed: 4.5 supplement for free!
http://www.informit.com/store/xcode-4-unleashed-9780672333279
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
