Why are strings copied in .NET?

Question

Since strings are immutable in .NET, why are they copied for simple operations such as Substring or Split? For example, by keeping a char[] value, int start and int length, a substring could be created to simply point to an existing string, and we could save the overhead of copying the string for many simple operations. So I wonder, why was the decision chosen to copy strings for such operations?

For example, was this done to support the current implementation of StringBuilder? Or to avoid keeping a reference to a large char[] when only a few characters are required? Or any other reason you can think of? Can you suggest pros and cons for such design?

As mentioned by @cletus and supported by @Jon Skeet, this is more like asking why .NET strings were built differently from Java in this aspect.

Answer 1

If you were re-using the same string to return substrings, what would happen when the main string goes out of scope?

In the best scenario, it would need to stay in memory and could not be collected until all substrings were also released, so you'll end-up using actually more memory.

That's just one of the issues.

In effect, the garbage collector would have few choices:

• keep the whole original string in memory, even through only a very short substring of it may be used.

• Release the parts of the original string that are not referenced and only keep the substring where it is. This would create a lot of fragmentation, meaning that the garbage collector would probably have to relocate the strings at some point: we'll end-up making a copy anyway.

I'm sure it has its use cases and it could sometimes be more efficient when working on substrings (say when working on large XML documents).
However, as Jon said, Java strings objects require more space, so if you have lots of small strings, they could actually use more memory than the way .Net does.

It's a tradeoff.
I think that if you're in a case where it really matter how memory is managed and you need to have a completely predictable behaviour, neither Java or .Net would be the best tools.

We use Garbage collectors because they are optimised to work efficiently in the vast majority of cases.
Knowing how they work is important, but whether they re-use strings or not is more of an optimisation left to the underlying framework and it should not leak too much to the surface.
GCs are, after all, here to help us.

Answer 2

In your substring example, that would mean we re-execute the substring logic every time we make a reference to the "new" string. The overhead of that alone makes it pretty obvious why we copy strings.

Answer 3

I guess the key is highlighting the difference between:

1. immutable string
2. string that is immutable exists for all eternity

What you are saying would work if strings were #2. However, while strings are immutable, they can be destroyed.

As you can see further they have their own costs:

1. immutable string - always making copies, as you have mentioned
2. string that is immutable exists for all eternity - keeping every string created forever

It is easy to see why #1 would be better :)

(But I don't mean that #2 is bad or dumb)

Answer 4

Trust me, you'd hate it if strings weren't immutable. To give you an example from Java: java.util.Date is mutable and it's a nightmare. Basiclaly it forces anyone who receives a data as a parameter or a function return must defensively copy it.

I can't speak for .Net strings but Java's substring operation actually does refer to the main string, meaning every string in Java has about a 16-20 byte overhead (pointer to the string, start index, end index, length and possibly something else). This has both advantages and disadvantages. It can be a real "gotcha" from a memory starvation point of view. On one project I worked on we had massive memory use. It turned out to be that we were receiving large messages (thousands of characters) and processing them with substrings. Because the substrings kept a reference to the original string, the original string was never cleaned up.

Now you can get around this by using the String constructor but that's not obvious and many people don't know that.

Basically substrings the way you're talking about are a real can of worms. Be careful what you wish for.

Answer 5

That's basically the way that Java works. There are a few benefits of the .NET way, IMO:

• Locality of reference - the data and the length are in the same place
• Fewer dereferences - the data is at a fixed point within the string object itself; no need to dereference another char array
• Lack of aliasing when you've got a single character substring of an originally-large string, as mentioned by Renaud.
• You end up with fewer objects and variables. In the case of a .NET string (assuming no wasted buffer space), the total size (on x86) is approximately 20+2*n bytes. In Java you've got the size of the array (12 + 2*n) bytes and the string itself (24 bytes: object overhead, reference, start and count; it also caches the hash if it's ever calculated it). So for an empty string, the .NET version takes about 20 bytes compared with Java's 36. Of course that's the worst case, and it'll only be that "constant difference" out - but if you use a lot of independent strings that could end up being significant. More for the garbage collector to look at, too.

Of course, the benefits are in terms of requiring less space when the aliasing above doesn't occur.

In the end it will depend on your usage - the compiler and runtime can't predict which usage pattern is more likely in your exact code.

There may also be interop benefits of the current string representation, but I don't know enough about that to say for sure.

EDIT: I'm not sure why your question has received so many somewhat-hostile answers. It's certainly not a "dumb" way of representing a string, and it clearly works. Fears about data loss and complexity are pretty much just FUD in this case, I believe - the Java string implementation is simple and robust. I personally suspect that the .NET way of doing things is more efficient in most programs, and I suspect MS did research to check that, but there will certainly be situations where the "shared" model works better.

Answer 6

Is what your saying this?

String s = "hello"; String v = s.Substring(1,4); //This should point to the last 4 characters of "hello" instead of creating a copy

If things were like that, can you imagine the internal links that the runtime would need to manage and how unsafe that would be from a data integrity point of view?

Copies of strings are made so that are managed easily by the runtime.

Answer 7

If the string object would contain a reference to the character data, that would mean that most strings would be two objects instead of one.