Dear Developers,
in Rev 23291 of GSString when you create Strings with [NSArray
componentsSeparatedByString:] the resulting GSCSubString objects have a
retain-count of 2 (see attached code). With WebObjects on Windows the
retain-count is 1. This makes a 200 MB difference when starting our App.
On 7 Jan 2013, at 21:11, Pirmin Braun wrote:
> Dear Developers,
>
> in Rev 23291 of GSString when you create Strings with [NSArray
> componentsSeparatedByString:] the resulting GSCSubString objects have a
> retain-count of 2 (see attached code). With WebObjects on Windows the
> retain-count
Am Mon, 7 Jan 2013 22:00:40 +
schrieb Tom Davie :
> Retain count means nothing. It may well have a retain count of 2, but be in
> the autorelease pool twice. Can you confirm that these actually are never
> released, and provide a small test case that demonstrates it?
>
I've tried this,
On 7 Jan 2013, at 22:15, Pirmin Braun wrote:
> Am Mon, 7 Jan 2013 22:00:40 +
> schrieb Tom Davie :
>
>> Retain count means nothing. It may well have a retain count of 2, but be in
>> the autorelease pool twice. Can you confirm that these actually are never
>> released, and provide a sm
Am Mon, 7 Jan 2013 22:28:13 +
schrieb Tom Davie :
> Instead, simply try to reduce this to a simple test case in which the string
> is not deallocated, yet all autorelease pools have been popped, and all
> allocs/retains balanced.
>
ok, here I've got a simple test:
svn checkout -r HEAD --n
On 7 Jan 2013, at 22:50, Pirmin Braun wrote:
> Am Mon, 7 Jan 2013 22:28:13 +
> schrieb Tom Davie :
>
>> Instead, simply try to reduce this to a simple test case in which the string
>> is not deallocated, yet all autorelease pools have been popped, and all
>> allocs/retains balanced.
>>
Am Mon, 7 Jan 2013 23:06:22 +
schrieb Tom Davie :
>
> On 7 Jan 2013, at 22:50, Pirmin Braun wrote:
>
> > Am Mon, 7 Jan 2013 22:28:13 +
> > schrieb Tom Davie :
> >
> >> Instead, simply try to reduce this to a simple test case in which the
> >> string is not deallocated, yet all autor
I've extended the test to reflect what happens in our App and now the problem
shows:
Code:
#import
int
main(int argc, char **argv)
{
NSString *s = @"fi-rst|sec-ond|thi-rd",*s1;
NSArray *a,*a1;
NSAutoreleasePool *pool =[NSAutoreleasePool new];
a = [s componentsSeparatedByString:
On 8 Jan 2013, at 00:28, Pirmin Braun wrote:
> the substrings of a substring retain their string from which they where
> splitted off;
> when those 2nd generation substrings are retained, the 1st generation
> substrings won't get deallocated;
> but they should, they are just intermediate objects
The behaviour in GNUstep is just as you describe, but this shouldn't lead to a
real memory leak. The original string still will get released when the
substrings get released. If the livespan of these strings should really be
different, the best you can do is to copy the substring and work with t
On 8 Jan 2013, at 00:28, Pirmin Braun wrote:
> the substrings of a substring retain their string from which they where
> splitted off;
> when those 2nd generation substrings are retained, the 1st generation
> substrings won't get deallocated;
> but they should, they are just intermediate object
Am Tue, 8 Jan 2013 09:43:22 +0100
schrieb Fred Kiefer :
> The behaviour in GNUstep is just as you describe, but this shouldn't lead to
> a real memory leak. The original string still will get released when the
> substrings get released. If the livespan of these strings should really be
> diffe
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:
NSString *s1 = [NSString stringWithUTF8String: [old UTF8String]];
(for better performance, you mi
Am Tue, 8 Jan 2013 14:51:07 +
schrieb David Chisnall :
> 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:
>
> NSString *s1 = [NSStr
On 8 Jan 2013, at 15:35, Pirmin Braun wrote:
> Am Tue, 8 Jan 2013 14:51:07 +
> schrieb David Chisnall :
>
>> 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
Why wouldn't you guys just use libobjc2 and ARC?
发自我的 iPad
在 2013-1-8，23:42，Richard Frith-Macdonald 写道：
>
> On 8 Jan 2013, at 15:35, Pirmin Braun wrote:
>
>> Am Tue, 8 Jan 2013 14:51:07 +
>> schrieb David Chisnall :
>>
>>> On 8 Jan 2013, at 14:41, Pirmin Braun wrote:
>>>
NSSt
On 8 Jan 2013, at 15:45, Chan Maxthon wrote:
> Why wouldn't you guys just use libobjc2 and ARC?
Or garbage collection ... which has been around for ages!
People don't use these features because they are all non-standard, in that they
aren't on most systems.
The vast majority of systems come w
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 +
schrieb David Chisnall :
On 8 Jan 2013, at 14:41, Pirmin Braun wrote:
NSString *s1 = [[a oai:i]copy];
For an immutable string, -copy just calls retai
On 13 Jan 2013, at 16:31, Fred Kiefer wrote:
> 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 singl
On 13.01.2013 18:19, David Chisnall wrote:
On 13 Jan 2013, at 16:31, Fred Kiefer wrote:
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
thanks to Fred who found out, that the problem are big autorelease pools, I
rewrote the startup process to create smaller pools which reduced the memory
consumption in my example from 265 to 184 MB.
But now I found the big drain:
[idmLines sortUsingKeyOrderArray:SOAFROM(@"tableName,attributeN
after implementing a compare: method in PBIDMLine and replacing the
sortUsingKeyOrderArray: by sortUsingSelector:@selector(compare:) it works; the
memory consumption is back down to 57 MB. Thanks to all who helped!
btw. the sortUsingKeyOrderArray: wasn't from GNUStep, I guess it came from GDL;
22 matches
Mail list logo
