aspose file tools*
The moose likes Performance and the fly likes String memory usage Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "String memory usage" Watch "String memory usage" New topic
Author

String memory usage

Brian Daniel
Greenhorn

Joined: Oct 30, 2001
Posts: 11
Currently I have a program in which I deal with large Strings and have many utility functions for picking apart various parts of the String. However, passing Strings as parameters and return values apparently eats up a ton of memory. Many sources suggest using char[] when possible instead of Strings. My question is, is there a way to "substring" an array in place?
As in I want char[x] to be char[0] now, and length to be length - x.
Brian Daniel
Greenhorn

Joined: Oct 30, 2001
Posts: 11
Or better yet, is there a String.substring call that instead of returning a new String, returns the same String object modified?
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Brian Daniel:
Or better yet, is there a String.substring call that instead of returning a new String, returns the same String object modified?

Strings are immutable, they cannot be modified. Whenever you do an operation on a String object which returns a String, e.g. concat or toUpperCase, the latter object would be a new object.
--Mark
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Actually, they do not always return a new object.
String performs some clever optimisations made possible by the very fact that it is immutable. For instance, toUpperCase() and friends don't return a new String unless there are any characters that actually need changing.
Likewise, substring() doesn't return a new String unless necessary - and even if it does, the new String is backed by the very same byte array as the original, so taking a substring() of a large String is not nearly as inefficient as you might think.
Most of the time this is good, but sometimes it is bad.Call this method a few times and watch all your available memory evaporate. The String returned by this method may be small, but it is still backed by a char array containing the entire contents of the huge file! Fortunately, it is very easy to fix this problem:The String(String) constructor is intelligent enough to see that the char array backing the original String is far too big. It will make a copy and the original array will be eligible for garbage collection. (It will not surprise you that if the char array is not too big, the new String will be backed by the same array as the old String - Strings are immutable, why make a copy?)
- Peter
Brian Daniel
Greenhorn

Joined: Oct 30, 2001
Posts: 11
I've only found Peter's example to be useful when the substring is an immensely small percentage of the whole string.
What I really would like to see is a mixture of the String and StringBuffer classes. There is no indexOf in StringBuffer, and there is no delete in String.
If the substring I'm attempting to remove is small, the following uses less memory:

If the substring I'm attempting to remove is large, the following uses less memory:

Brian Daniel
Greenhorn

Joined: Oct 30, 2001
Posts: 11
Actually, I just discovered this uses the least memory in all cases, despite that it looks so cumbersome:

Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Peter den Haan:
Actually, they do not always return a new object.
String performs some clever optimisations made possible by the very fact that it is immutable.


Touche! You are right. I was debating whether or not to get into this level of detail, but I was in a hurry. The bottom line is String are immutable. A particular JVM may be clever and reuse the same String object--although this can't be assumed. Most JVMs use a String pool, anyway. That is, if I create two Strings, "Foo", in totally serpate places in my code, with no relation to one another, the JVM will still probably only have one "Foo" object in memory.
--Mark
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: String memory usage