Hi, This change is 6 months old now. I wonder if Oracle received any complaints from the users since then. I mean complaints that are based on real observations of performance degradation in real code - not only speculation.
Regards, Peter 2012/11/15 Zhong Yu <zhong.j...@gmail.com> > Since this change is to achieve minor performance boost, it's not fair > to defend it by saying that it only incurs minor performance > penalties. > > Java programs are infested with strings, most of which could have used > a more appropriate type, but it is the insane reality. Any change to > the behavior of strings should have been backed up by a much more > thorough analysis. > > Every usage of substring() was (hopefully) the result of some > conscious reasoning about space-time. Even if this change does not > significantly alter an application's performance, it invalidates all > the reasoning, that's the worst blow in my book. There's no problem if > substring() does copying from day one, but 17 years have passed. > > Zhong Yu > > On Wed, Nov 14, 2012 at 6:58 PM, Vitaly Davidovich <vita...@gmail.com> > wrote: > > Personally, I feel like the concern is a bit overstated: > > > > 1) the n in O(n) is likely actually fairly small in practice (at least in > > what I'd consider sane code) > > 2) I think a lot of people that worry about perf probably aren't using > > substring() anyway > > 3) copying char[] is optimized by jit - this is basically a memcpy()-like > > call, which modern machines handle well > > 4) the upside is strings are 8 bytes smaller > > 5) .NET substring() has always allocated new storage (via an optimized > > internal VM call) and never shared the char[] and I haven't come across > any > > complaints or seen serious perf problems myself (granted I seldom use > > substring) > > > > So I don't know if this is anything to worry about in practice. > > > > Sent from my phone > > > > On Nov 14, 2012 5:26 PM, "Zhong Yu" <zhong.j...@gmail.com> wrote: > >> > >> On 06/03/2012 11:35 PM, Mike Duigou wrote: > >> > [I trimmed the distribution list] > >> > > >> > On Jun 3 2012, at 13:44 , Peter Levart wrote: > >> > > >> >> On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.comwrote: > >> >>> Changeset: 2c773daa825d > >> >>> Author: mduigou > >> >>> Date: 2012-05-17 10:06 -0700 > >> >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d > >> >>> > >> >>> 6924259: Remove offset and count fields from java.lang.String > >> >>> Summary: Removes the use of shared character array buffers by String > >> >>> along > >> >>> with the two fields needed to support the use of shared buffers. > >> >> Wow, that's quite a change. > >> > Indeed. It was a long time in development. It is a change which is > >> > expected to be overall beneficial though and in the general case a > positive > >> > win. > >> > >> Wow! > >> > >> If the previous behavior of substring() was once a bug, by now it has > >> become a well known feature. People know about it, and people depend > >> on it. > >> > >> This change is a big surprise. Changing O(1) to O(n) is a breach of > >> contract. It'll break lots of old code; and meanwhile lots of new code > >> are still being written based on the old assumption. After people > >> learned about the new behavior, they need to comb through and rewrite > >> their code. > >> > >> The worst part is the same code performs very differently on different > >> versions of JDK. What's a programmer supposed to do if his code > >> targets JDK6 and above? If the cost of strings are no longer certain, > >> what else can we believe in? > >> > >> Is there any chance in hell to roll it back? Maybe add a new method > >> for the new behavior? > >> > >> Zhong Yu >
