On 08.01.2013 16:42, Richard Frith-Macdonald wrote:
On 8 Jan 2013, at 15:35, Pirmin Braun wrote:
Am Tue, 8 Jan 2013 14:51:07 +0000
schrieb David Chisnall <[email protected]> :
On 8 Jan 2013, at 14:41, Pirmin Braun wrote:
NSString *s1 = [[a oai:i]copy];
For an immutable string, -copy just calls retain. If you want to actually copy
the string, do something like:
Not true for substrings, here copy generates a separate object that has
no connection to the parent.
NSString *s1 = [NSString stringWithUTF8String: [old UTF8String]];
(for better performance, you might want to use getCharacters:range: and a
temporary buffer, so that the old string doesn't have to create a new
autoreleased buffer).
David
-- Sent from my STANTEC-ZEBRA
ok, changed it like this:
NSArray *a = [self componentsSeparatedByString:s];
NSMutableArray *ma = [NSMutableArray arrayWithCapacity:[a count]];
int i,j;
// deep copy of a
for(i=0,j=[a count];i<j;i++){
[ma addObject:[NSString stringWithUTF8String:[[a oai:i]UTF8String]]];
}
return [NSArray arrayWithArray:ma]; // immutable
but also no difference; I give up. For the moment.
You need to wrap things in an autorelease pool so that you can release the
array by releasing the pool ...
1. create pool
2. call -componentsSeparatedByString:
3. make deep copy of resulting array
4. release pool
5. autorelease and return the copied array
I spend quite some time to analyse the cause of Pirmin's problem. In the
end it turned out that most of the memory was lost in the
NSAutoreleasePool itself. We cache the instances of this class and when
code uses a lot of objects with a single pool that pool will get huge
and even after it is released that addition memory will be kept.
This is fine in the normal usage of auto release pools where we expect
that the next usage will use about as many objects as a previous one. In
Pirmin's case the auto release pool that gets used at the start up
becomes huge and later on most of that memory is never needed again.
Of course the best solution is to use multiple auto release pools during
the start up, for each operation a separate one. Still we should think
about a way to get rid of these monster pools, when a badly written
program generates one.
Fred
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
