[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: big memory leak in GSString
From: |
David Chisnall |
Subject: |
Re: big memory leak in GSString |
Date: |
Tue, 8 Jan 2013 07:48:32 +0000 |
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;
This is a known difference in implementation between the Apple and GNUstep
implementations. GNUstep assumes that strings created as substrings are likely
to have a shorter lifespan than the original string and so, if safe to do so
(i.e. the original string is immutable and owns its contents). This behaviour
is very useful when tokenising a string, because it means that the memory usage
is
Now, in this case, you are looking at very short strings so it's less clear
that it's an advantage. If you are on a 64-bit system, then this will use
GSTinyString, which hides a 7-character ASCII string inside a pointer, so these
strings are effectively free, their retain count methods are no-ops, and they
don't refer to the original string.
We should possibly provide some kind of heuristic that says if the substring is
less than the size of a couple of pointers that it's better to copy the data
than to reference it.
David
--
This email complies with ISO 3103
- big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString, Tom Davie, 2013/01/07
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString, Tom Davie, 2013/01/07
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString, Tom Davie, 2013/01/07
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString,
David Chisnall <=
- 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