It's nice to see someone that I agree with on performance optimization. So many people take either a dogmatic, or a scattershot approach to optimization.
The most important thing is to measure. This quote sums it up: "When you can measure what you are speaking about and express it in numbers you know something about it, but when you cannot measure it, when you cannot express it in numbers, your knowledge is a meager and unsatisfactory kind. It may be the beginning of knowledge but you have scarcely in your thoughts advanced to a stage of science." - from the Popular Lectures and Addresses of Lord William Thomson Kelvin in 1891 - 1894. -----Original Message----- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2003 9:31 AM To: Tomcat Users List Subject: Re: Tomcat Settings and Performance Steve, > Maybe this is common knowledge, but you know never to do this right? > > String x = "a" + "b"; > > You have to do something like this: > > StringBuffer b = new StringBuffer(); > b.append("a"); > b.append("b"); > > Using StringBuffer vastly improves performance. Ugh! This is like saying "never use goto". In this example, you are completely wrong: String x = "a" + "b"; compiles to: load x, "ab" which is a lot better than: getclass StringBuffer dup dup new load "a" invoke "append" load "b" invoke "append" store x The Java compiler will take constant string expressions that are concatenated and perform the concatenation for you. The code is smaller. However, if you are doing a lot of string (dynamic) processing, than using StringBuffer is to your advantage, because lots of string operations are converted (again, by the compiler) into uses of the StringBuffer class. There's also nothing wrong with doing this: String path = SOME_STOCK_PATH + argv[0]; Because if you want a String object that looks like "some/stock/path/mypath", and not a StringBuffer containing those characters, then why would you write this: StringBuffer sb = new StringBuffer(); sb.append(SOME_STOCK_PATH); sb.append(argv[0]); String whatIreallyWanted = sb.toString(); This is exactly what the compiler will do with the code. You can't improve the speed, because you are just doing compiler work. What have you gained? Loss of readability, which I think is a poor tradeoff for no benefit. There is one was to make it "better". Do this: StringBuffer sb = new StringBuffer(SOME_STOCK_PATH).append(argv[0]); or even StringBuffer sb = new StringBuffer(SOME_STOCK_PATH.length() + argv[0].length()).append(SOME_STOCK_PATH).append(argv[0]); At least then you'll have a somewhat appropriately sized array, and you'll avoid the re-allocation of arrays required to handle the string sizes. Over the versions of the JVM, StringBuffer and String performance have been improved; the implementors know that String objects get created all the time and are used heavily in the standard library and pretty much everywhere else. Bottom line: don't resort to "performance" "improvements" at the expense of readability of your code. I consider this to be a classic case of premature optimization. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
