When you've worked with languages with a garbage collector, having to worry about memory management
It's an illusion to think that in a language with a garbage collector you do not have to worry about memory management. To give an example: take a function that takes a substring of a string.
1. If a substring function returns a string with the same underlying character array (just with different start/end indices), you may be wasting memory with very large strings of which you only care about small substrings.
2. If a substring function returns a string with an underlying character array that is a copy of the particular substring, you may waste a lot of memory when you have a lot of (partially) overlapping substrings. Moreover, the substring operation is O(n) rather than O(1).
In other words, in any non-trivial application working with strings you want to know the allocation behaviour of common string operations.
It's an illusion to think that in a language with a garbage collector you do not have to worry about memory management. To give an example: take a function that takes a substring of a string.
1. If a substring function returns a string with the same underlying character array (just with different start/end indices), you may be wasting memory with very large strings of which you only care about small substrings.
2. If a substring function returns a string with an underlying character array that is a copy of the particular substring, you may waste a lot of memory when you have a lot of (partially) overlapping substrings. Moreover, the substring operation is O(n) rather than O(1).
In other words, in any non-trivial application working with strings you want to know the allocation behaviour of common string operations.