[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Partially solved: big memory leak in GSString
From: |
Pirmin Braun |
Subject: |
Partially solved: big memory leak in GSString |
Date: |
Mon, 14 Jan 2013 12:31:47 +0100 |
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,attributeName")];
eats 160 MB.
idmLines is a mutable array with approx. 34000 instances of PBIDMLine, a small
4 string data bearing object
any ideas? known (old) bug?
--
Pirmin Braun - IntarS Unternehmenssoftware GmbH - Sinziger Str. 29a - 53424
Remagen
+49 2642 308288 +49 174 9747584 - skype:pirminb www.intars.de address@hidden
intars.sourceforge.net
Geschäftsführer: Pirmin Braun, Ralf Engelhardt Registergericht: Amtsgericht
Coburg HRB3136
- Re: big memory leak in GSString, (continued)
- Re: big memory leak in GSString, Fred Kiefer, 2013/01/08
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/08
- Re: big memory leak in GSString, David Chisnall, 2013/01/08
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/08
- Re: big memory leak in GSString, Richard Frith-Macdonald, 2013/01/08
- Re: big memory leak in GSString, Chan Maxthon, 2013/01/08
- Re: big memory leak in GSString, Richard Frith-Macdonald, 2013/01/08
- Re: big memory leak in GSString, Fred Kiefer, 2013/01/13
- Re: big memory leak in GSString, David Chisnall, 2013/01/13
- Re: big memory leak in GSString, Fred Kiefer, 2013/01/13
- Partially solved: big memory leak in GSString,
Pirmin Braun <=
- Re: Solved: big memory leak in GSString, Pirmin Braun, 2013/01/14
- Re: big memory leak in GSString, Richard Frith-Macdonald, 2013/01/08