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.com wrote: > >>> 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 >
