I know that strings in C# are immutable i.e. when I change the value of a string variable a new string variable with the same name is created with the new value and the older one is collected by GC. Am I right?
string s1 = "abc";
s1 = s1.Substring(0, 1);
If what I said is right, then my doubt is if a new string is created, then is it created in the same memory location?
if a new string is created, then is it created in the same memory location?
No, a separate string object is created, in a separate bit of memory.
You're then replacing the value of s1 with a reference to the newly-created string. That may or may not mean that the original string can be garbage collected - it depends on whether anything else has references to it. In the case of a string constant (as in your example, with a string literal) I suspect that won't be garbage collected anyway, although it's an implementation detail.
If you have:
string text = "original";
text = text.Substring(0, 5);
text = text.Substring(0, 3);
then the intermediate string created by the first call to Substring will be eligible for garbage collection, because nothing else refers to it. That doesn't mean it will be garbage collected immediately though, and it certainly doesn't mean that its memory will be reused for the string created by the final line.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I know strings are inmutable, once created we cannot change it, I've read that if we create a new string object and we assign a value to it and then we assign another value to the same string object internally there is actually another object created and assigned with the new value. Let's say I have:
string str = "dog";
str = "cat";
If I write Console.WriteLine(str); it returns cat.
So internally there are two objects? But they have the same name? How does it works? I've made some research on google but I have not find yet something convincing enough to me so I can clarify my thoughts about this.
I know strings are reference types, so we have an object in the stack with a reference to a value in the heap, what's happening in this case?(see code above).
I've upload a picture, apologize me if I'm wrong about the idea of the stack and the heap that's why I'm asking this question.
Does the picture reflects what happens in the first line of code(string str = "dog";)? And then what should happen in the second line of code?? The dog value in the heap changes? And then a new object in the stack is created referencing it? Then what happens with the object that was there before? Do they have the same name?
I'm sorry for so many questions but I think that is very important to understand this correctly and to know what's happening behind the scenes...
When you assign str to "dog", it does as you describe above in memory: the reference variable str now is "pointing at" the location of the string you've just instantiated.
str => MEMORY LOCATION "1": "dog"
MEMORY LOCATION "2":
MEMORY LOCATION "3":
When str is reassigned to your new string, "cat", it too is created in memory, and now str is adjusted so it points at "cat" in the new location.
MEMORY LOCATION "1": "dog"
str => MEMORY LOCATION "2": "cat"
MEMORY LOCATION "3":
What happens to "dog"? It's effectively inaccessible now, since we no longer have a reference to its location (in the memory, heap, terms are interchangeable in this situation). Later, when the Garbage collector reviews the memory for cleaning, it'll realize that there is nothing referencing "dog" and it will mark the memory for being deleted and replaced as needed.
You're close. Your picture accurately represents what happens in the first line of code. However, things are a little different from what you describe for the second line of code.
For the line str = "cat";, a second string object is created in the heap and the str variable is changed to refer to that new object. You're left with str pointing to "cat" and an orphan "dog" object on the heap with no references to it.
The "dog" object might be cleaned up by the garbage collector because there are no references to it.
review String Interning or .Net String Intern table or CLR Intern Pool.
Basically, the Common Language Runtime (CLR) maintains a table of [unique] string values, and whenever you manipulate a string in your code, the CLR examines this intern table to see if the new value you are trying to create is already in there or not. If it is, it just reassigns the variable you are modifying to point to that entry in the intern pool. If not, it adds the value to the pool and returns that new reference. Old values in the pool, no longer referenced by variables, get garbage collected.
Yes, there are two objects. No, they don't have the same name. Try not to think of a variable as a "name" for the object itself per se - it's more like a temporary name for the object's location in memory. (The reason it's somewhat misleading to think of a variable as a "name" for the object is that you can have several variables referring to the same object; it's not the case that the object has several "names" per se, or that there are several objects - that's just how you happen to be storing the reference).
"string str" initially has a reference to the string "dog." After you assign "cat" to "str", the variable now has a reference to the string "cat."
Both strings still exist in memory (at least temporarily), but the "dog" string is no longer accessible because you don't have a reference to it (and therefore no longer "know" its location). You don't know in advance how long they'll both exist in memory though since the garbage collector could delete the "dog" string from memory at any point since there are no longer any references to it.
You're correct about the value on the stack with the reference to the object on the heap by the way - that's a good distinction.
I was having a discussion with a colleague the other day about this hypothetical situation. Consider this pseudocode:
public void Main()
{
MyDto dto = Repository.GetDto();
foreach(var row in dto.Rows)
{
ProcessStrings(row);
}
}
public void ProcessStrings(DataRow row)
{
string string1 = GetStringFromDataRow(row, 1);
string string2 = GetStringFromDataRow(row, 2);
// do something with the strings
}
Then this functionally identical alternative:
public void Main()
{
string1 = null;
string2 = null,
MyDto dto = Repository.GetDto();
foreach(var row in dto.Rows)
{
ProcessStrings(row, string1, string2)
}
}
public void ProcessStrings(DataRow row, string string1, string string2)
{
string1 = GetStringFromDataRow(row, 1);
string2 = GetStringFromDataRow(row, 2);
// do something with the strings
}
How will these differ in processing when running the compiled code? Are we right in thinking the second version is marginally more efficient because the string variables will take up less memory and only be disposed once, whereas in the first version, they're disposed of on each pass of the loop?
Would it make any difference if the strings in the second version were passed by ref or as out parameters?
When you're dealing with "marginally more efficient" level of optimizations you risk not seeing the whole picture and end up being "marginally less efficient".
This answer here risks the same thing, but with that caveat, let's look at the hypothesis:
Storing a string into a variable creates a new instance of the string
No, not at all. A string is an object, what you're storing in the variable is a reference to that object. On 32-bit systems this reference is 4 bytes in size, on 64-bit it is 8. Nothing more, nothing less. Moving 4/8 bytes around is overhead that you're not really going to notice a lot.
So neither of the two examples, with the very little information we have about the makings of the methods being called, creates more or less strings than the other so on this count they're equivalent.
So what is different?
Well in one example you're storing the two string references into local variables. This is most likely going to be cpu registers. Could be memory on the stack. Hard to say, depends on the rest of the code. Does it matter? Highly unlikely.
In the other example you're passing in two parameters as null and then reusing those parameters locally. These parameters can be passed as cpu registers or stack memory. Same as the other. Did it matter? Not at all.
So most likely there is going to be absolutely no difference at all.
Note one thing, you're mentioning "disposal". This term is reserved for the usage of objects implementing IDisposable and then the act of disposing of these by calling IDisposable.Dispose on those objects. Strings are not such objects, this is not relevant to this question.
If, instead, by disposal you mean "garbage collection", then since I already established that neither of the two examples creates more or less objects than the others due to the differences you asked about, this is also irrelevant.
This is not important, however. It isn't important what you or I or your colleague thinks is going to have an effect. Knowing is quite different, which leads me to...
The real tip I can give about optimization:
Measure
Measure
Measure
Understand
Verify that you understand it correctly
Change, if possible
You measure, use a profiler to find the real bottlenecks and real time spenders in your code, then understand why those are bottlenecks, then ensure your understanding is correct, then you can see if you can change it.
In your code I will venture a guess that if you were to profile your program you would find that those two examples will have absolutely no effect whatsoever on the running time. If they do have effect it is going to be on order of nanoseconds. Most likely, the very act of looking at the profiler results will give you one or more "huh, that's odd" realizations about your program, and you'll find bottlenecks that are far bigger fish than the variables in play here.
In both of your alternatives, GetStringFromDataRow creates new string every time. Whether you store a reference to this string in a local variable or in argument parameter variable (which is essentially not much different from local variable in your case) does not matter. Imagine you even not assigned result of GetStringFromDataRow to any variable - instance of string is still created and stored somewhere in memory until garbage collected. If you would pass your strings by reference - it won't make much difference. You will be able to reuse memory location to store reference to created string (you can think of it as the memory address of string instance), but not memory location for string contents.
I was wondering how does .NET's string.Remove() method operates regarding memory.
If I have the following piece of code:
string sample = "abc";
sample = sample.Remove(0);
What will actually happen in memory?
If I understand correctly, We've allocated a string consisting of 3 chars, and then we removed all of them on a new copy of the string, assigned the copy to the old reference, by that overriding it, and then what? What happens to those 3 characters?
If we're not pointing to them anymore, and they're not freed up (at least not that I'm aware of), they will remain in memory as garbage.
However, I'm sure the CLR has some way of detecting it and freeing them up eventually.
So any of you guys know what happens here? Thanks in advance!
First Remove is going to create a new string that has no characters in it (an empty string). This will involve the allocation of a char array an a string object to wrap it. Then you'll assign a reference to that string to your local variable.
Since the string "abc" is a literal string, it'll still exist in the intern pool, unless you've disabled interning of compile time literal strings, so it won't be garbage collected.
So in summary, you've created two new objects and changed the reference of the variable sample from the old object to the new one.
According to the source code: http://referencesource.microsoft.com/#mscorlib/system/string.cs
The method Remove() allocates a new string object and returns the results to you
In your code sample, the sample variable is replaced with a new string object that no longer has the first character
When the garbage collector fires, the orphaned string is reclaimed.
I wanted to do this in order to test my code. I suppose I could make another wrapper around the weakreference object, but would prefer to work directly to simulate the original object getting reclaimed.
This is the code that I have so far
var myString = "someString";
var myStringRef = new WeakReference(myString);
myString = null;
GC.Collect();
Assert.IsFalse(myStringRef.IsAlive) //I want this to pass, but it failed. IsAlive is still true.
What can I do to force the last line above to not fail (ie. !IsAlive)
I have some framework logic that does housekeeping based on the status of the weakreference. I want to be able to test that logic, to do so, I need to be able to change the weakreference state at will - so how can I do this?
I wonder if this has something to due with the fact that strings are interned, because the following test passes:
var myObject = new object();
var myObjectRef = new WeakReference(myObject);
myObject = null;
GC.Collect();
Assert.IsFalse(myObjectRef.IsAlive);
Instead of hardcoding the string into the source file, read it in via an external source. For example, you can create a TestStrings.txt file where your string(s) are placed and use this.
string myString = File.ReadAllText(#"TestStrings.txt");
var myStringRef = new WeakReference(myString);
myString = null;
GC.Collect();
Assert.IsFalse(myStringRef.IsAlive);
This should return false. As mentioned in the other answer, this is indeed due to string interning.
By reading the text from an external source the strings won't be interned here which seems to be what you want for this test. (You can check if the string is interned by using String.IsInterned method).
Literal strings are interned by default, so despite the fact that you null myString the instance is still rooted by the intern table.
Please see my answer to this question for details about how interning is handled.
to do so, I need to be able to change the weakreference state at will
You could build an abstraction around WeakReference and make that testable (using an interface or a "test mode" which allows you to change the value returned by IsAlive).
I am currently working on a very large legacy application which handles a large amount of string data gathered from various sources (IE, names, identifiers, common codes relating to the business etc). This data alone can take up to 200 meg of ram in the application process.
A colleague of mine mentioned one possible strategy to reduce the memory footprint (as a lot of the individual strings are duplicate across the data sets), would be to "cache" the recurring strings in a dictionary and re-use them when required. So for example…
public class StringCacher()
{
public readonly Dictionary<string, string> _stringCache;
public StringCacher()
{
_stringCache = new Dictionary<string, string>();
}
public string AddOrReuse(string stringToCache)
{
if (_stringCache.ContainsKey(stringToCache)
_stringCache[stringToCache] = stringToCache;
return _stringCache[stringToCache];
}
}
Then to use this caching...
public IEnumerable<string> IncomingData()
{
var stringCache = new StringCacher();
var dataList = new List<string>();
// Add the data, a fair amount of the strings will be the same.
dataList.Add(stringCache.AddOrReuse("AAAA"));
dataList.Add(stringCache.AddOrReuse("BBBB"));
dataList.Add(stringCache.AddOrReuse("AAAA"));
dataList.Add(stringCache.AddOrReuse("CCCC"));
dataList.Add(stringCache.AddOrReuse("AAAA"));
return dataList;
}
As strings are immutable and a lot of internal work is done by the framework to make them work in a similar way to value types i'm half thinking that this will just create a copy of each the string into the dictionary and just double the amount of memory used rather than just pass a reference to the string stored in the dictionary (which is what my colleague is assuming).
So taking into account that this will be run on a massive set of string data...
Is this going to save any memory, assuming that 30% of the string values will be used twice or more?
Is the assumption that this will even work correct?
This is essentially what string interning is, except you don't have to worry how it works. In your example you are still creating a string, then comparing it, then leaving the copy to be disposed of. .NET will do this for you in runtime.
See also String.Intern and Optimizing C# String Performance (C Calvert)
If a new string is created with code like (String goober1 = "foo"; String goober2 = "foo";) shown in lines 18 and 19, then the intern table is checked. If your string is already in there, then both variables will point at the same block of memory maintained by the intern table.
So, you don't have to roll your own - it won't really provide any advantage. EDIT UNLESS: your strings don't usually live for as long as your AppDomain - interned strings live for the lifetime of the AppDomain, which is not necessarily great for GC. If you want short lived strings, then you want a pool. From String.Intern:
If you are trying to reduce the total amount of memory your application allocates, keep in mind that interning a string has two unwanted side effects. First, the memory allocated for interned String objects is not likely be released until the common language runtime (CLR) terminates. The reason is that the CLR's reference to the interned String object can persist after your application, or even your application domain, terminates. ...
EDIT 2 Also see Jon Skeets SO answer here
This is already built-in .NET, it's called String.Intern, no need to reinvent.
You can acheive this using the built in .Net functionality.
When you initialise your string, make a call to string.Intern() with your string.
For example:
dataList.Add(string.Intern("AAAA"));
Every subsequent call with the same string will use the same reference in memory. So if you have 1000 AAAAs, only 1 copy of AAAA is stored in memory.