Ok, I'm working with some Strings, and these Strings will get remade up to an infinite number of times, and I know that a new object is created each time.
So, which is worse..

Keep using the String, and have the value continously change, or

Use a StringBuffer, and continously delete the current text so that the upcoming read text can be the only thing in the StringBuffer.

I hope that makes sense!

String thing = "asdfasdfadf"

thing.replace(thing, "new text");

The Strings will all take up memory as they'll be stored in the String constant pool.
The next time an identical String is used it will be pulled from the pool instead.

This assumes you do NOT use the constructors for String explicitly as that prevents the pool from being used.

What about using Strings like I've been doing. Assigning it a new value each time, and I guess it creates a new Object. Will Java's automatic garbage collection not take care of the unused objects?

If each String is different from all the others then yes, a new one is created each time.
When and if they're deleted at some point is up to the JVM implementation.

I'm not quite sure what you're planning to do with a StringBuffer instead.
If you just add String literals to it it won't save any memory, if the Strings are retrieved on the fly from external sources (say incoming network data) then you should indeed most likely prefer StringBuffers.

Strings are immutable. Meaning you can NEVER change them.
So if I do this:
I've just made 3 permenant strings. I've made "Pig" "Horse" and "PigHorse". All strings are constants, so they will never be changed. When you change a reference to string by reassigning it a new string, you've created a new one. For example:
You now have 3 strings, you have "Pig" "Horse" and "Cow".

If you're going to be working with strings, use a stringbuffer. You will gain far more performance by doing that then using string objects.

Actually, this was about network data. I've made a webcrawler and finally got it to work, but it's extremely slow.

See, I read the HTML code one line at a time, and this one String is set equal to the read line. So, If I have hundreds of lines of code, and thousands of URLs, then I know part of my speed problem is with the Strings.

Could be, but it's more likely with the way you treat them, how you process them.

Or it is with the network...

I have played around with, A little while ago, an app (a profiler) that checks how optermised your java code is (tells you a range of information on each object, Like memory, and cpu time etc..) something like this would be great for figuring out exactly what is taking alot of time to process..

I might even be worth making some code to calculate the time difference so you can find the time it takes to read the string and the time it takes to process that string etc..

Perhaps try the java interpreters profiler


The best approch for strings is prolly using the same one over and over again, the garbage collection process and the object creation both take time

Too see howmuch your using garbage collection use



A nice list of free java profilers

Just looked at the last post if its still the same
you can avoid making a string
URL newURL = new URL(text.substring(numFirst+9, numEnd));


also are you still running run() from the tread, Im just thinking running to many treads could be similar to running too many forks (forkbombing) it may make the JVM just die in the butt attempting to figure out who to give time, I have never seen what happens if you run alot of treads so im just making assumptions.

But i have a suspision that there is a strong possability that thats why its happing