«

The String class was modified in JDK 1.7.0_6.
String.substring that was 0(1) before JDK 1.7.0_6, now becomes O(n)

All is well explained at :
http://java-performance.info/changes...java-1-7-0_06/

I wrote a small test:
https://gist.github.com/4692960

java -Xms128M -Xmx128M teststring.Main 100000 1000000

On my desktop:
jdk 1.7.0_11 => 33 seconds / 252 KBytes Memory
jdk 1.6.0_38 => 25 milliseconds / 782 KBytes Memory
more than 1000 times faster ! ( Ok! for this stupid test )

I don't think it is a good improvement ! Uses less memory, but you
retrieve it, when the object is garbaged
What do you think about this ?

--
Cordialement
Jean-Louis Pasturel

On 2/1/2013 10:33 AM, jlp wrote:
> What do you think about this ?
>

I think micro-benchmarks don't work.

Le 01/02/2013 19:38, markspace a écrit :
> On 2/1/2013 10:33 AM, jlp wrote:
>> What do you think about this ?
>>
>
> I think micro-benchmarks don't work.
>
>

What is wrong in this test ?

--
Cordialement
Jean-Louis Pasturel

On 2/1/2013 10:42 AM, jlp wrote:
> Le 01/02/2013 19:38, markspace a écrit :
>> On 2/1/2013 10:33 AM, jlp wrote:
>>> What do you think about this ?
>>>
>>
>> I think micro-benchmarks don't work.
>>
>>
>
> What is wrong in this test ?
>


It's a micro-benchmark.

Le 01/02/2013 19:45, markspace a écrit :
> On 2/1/2013 10:42 AM, jlp wrote:
>> Le 01/02/2013 19:38, markspace a écrit :
>>> On 2/1/2013 10:33 AM, jlp wrote:
>>>> What do you think about this ?
>>>>
>>>
>>> I think micro-benchmarks don't work.
>>>
>>>
>>
>> What is wrong in this test ?
>>
>
>
> It's a micro-benchmark.
>
ok

But it seems problematic in "real world"
https://jira.springsource.org/browse...story-tabpanel
http://grokbase.com/t/gg/scala-user/...rouped-so-slow

--
Cordialement
Jean-Louis Pasturel

On 2/1/2013 10:57 AM, jlp wrote:

> But it seems problematic in "real world"
> https://jira.springsource.org/browse...story-tabpanel


That's a better test, using production code. However, note that it's
scoped to only one small portion of the code, only while loading a lot
of small scripts.

It's really common for code that was once "working" to suddenly develop
undesirable characteristics as it's exposed to new input or new
environments or new anything. It's just something that happens and part
of the normal maintenance of code.

What do I think of it? It's normal.

There seems to be more going on with Strings:
http://bugs.sun.com/bugdatabase/view...bug_id=6962931

But I didn't find the original change request (CR)
or request for enhancement concerning the copy
semantics. There was some estimate on applications
impact and allotment for redesigning applications.

I didn't know about hash32 thing in the link below.
Your micro benchmark doesn't test hashCode, does it?

jlp schrieb:
> The String class was modified in JDK 1.7.0_6.
> String.substring that was 0(1) before JDK 1.7.0_6, now becomes O(n)
>
> All is well explained at :
> http://java-performance.info/changes...java-1-7-0_06/
>
> I wrote a small test:
> https://gist.github.com/4692960
>
> java -Xms128M -Xmx128M teststring.Main 100000 1000000
>
> On my desktop:
> jdk 1.7.0_11 => 33 seconds / 252 KBytes Memory
> jdk 1.6.0_38 => 25 milliseconds / 782 KBytes Memory
> more than 1000 times faster ! ( Ok! for this stupid test )
>
> I don't think it is a good improvement ! Uses less memory, but you
> retrieve it, when the object is garbaged
> What do you think about this ?
>

In article <510c0a6a$0$8985$> ,
jlp <> wrote:

> The String class was modified in JDK 1.7.0_6.
> String.substring that was 0(1) before JDK 1.7.0_6, now becomes O(n)
>
> All is well explained at :
> http://java-performance.info/changes...java-1-7-0_06/
>
> I wrote a small test:
> https://gist.github.com/4692960
>
> java -Xms128M -Xmx128M teststring.Main 100000 1000000
>
> On my desktop:
> jdk 1.7.0_11 => 33 seconds / 252 KBytes Memory
> jdk 1.6.0_38 => 25 milliseconds / 782 KBytes Memory
> more than 1000 times faster ! ( Ok! for this stupid test )
>
> I don't think it is a good improvement ! Uses less memory, but you
> retrieve it, when the object is garbaged
> What do you think about this ?

It's an unbelievable change. Buffer sharing in Java 1-6 had the simple
workaround of calling the String(String) constructor. There's no
workaround for Strings getting much slower in Java 7+.

What Oracle did in Java 7 would only make sense if CharSequence had
buffer sharing and better support. I just checked Java 7, and
CharSequence looks more useless than ever. String.subSequence()
allocates a new char[] and the usual parsers (Integer, Long, Float)
still only accept a String. Slow Strings it is.


Side rant:
Sun broke buffer sharing between StringBuffer and String back in Java 5.
The reason was so that AbstractStringBuilder class could support the
implementations for both StringBuffer and StringBuilder. Had they kept
the implementations split, we could still have a very fast
StringBuffer.toString(). As a final F-U, none of classes can be
extended even through there's no buffer sharing that can be hacked.
--
I will not see posts from Google because I must filter them as spam

On 2/1/2013 8:58 PM, Kevin McMurtrie wrote:

> and the usual parsers (Integer, Long, Float)
>still only accept a String. Slow Strings it is.
>

This I agree is a bit of a bummer, it would be useful for the parsers to
take CharSequence for flexibility. Integers aren't hard to parse but
floats and doubles are non-trivial.

Note however that Scanner accepts both Readable (a Reader) and
ReadableByteChannel in its constructors.

>
> Side rant:
> Sun broke buffer sharing between StringBuffer and String back in Java 5.

Probably because Strings needed to be immutable and there's no way to do
that when sharing a mutable buffer.

> we could still have a very fast
> StringBuffer.toString().

Nope, see above.

> As a final F-U, none of classes can be
> extended even through there's no buffer sharing that can be hacked.
>

Probably because they don't want you doing stupid broken things, like
trying to share buffers between immutable and mutable objects.

I still agree that CharSequence could be made more useful though, that's
a good idea. Hmmm.

In article <keid8j$2og$>,
markspace <> wrote:

> On 2/1/2013 8:58 PM, Kevin McMurtrie wrote:
>
> > and the usual parsers (Integer, Long, Float)
> >still only accept a String. Slow Strings it is.
> >
>
> This I agree is a bit of a bummer, it would be useful for the parsers to
> take CharSequence for flexibility. Integers aren't hard to parse but
> floats and doubles are non-trivial.
>
> Note however that Scanner accepts both Readable (a Reader) and
> ReadableByteChannel in its constructors.
>
> >
> > Side rant:
> > Sun broke buffer sharing between StringBuffer and String back in Java 5.
>
> Probably because Strings needed to be immutable and there's no way to do
> that when sharing a mutable buffer.

The original StringBuffer class was synchronized, final, and protected
its internal char[]. There was no way to trick it into altering the
buffer after turning it into String. At worst it was the same speed as
today's StringBuilder. For the common case of being a single-use
object, it was much faster.


> > we could still have a very fast
> > StringBuffer.toString().
>
> Nope, see above.
>
> > As a final F-U, none of classes can be
> > extended even through there's no buffer sharing that can be hacked.
> >
>
> Probably because they don't want you doing stupid broken things, like
> trying to share buffers between immutable and mutable objects.
>
> I still agree that CharSequence could be made more useful though, that's
> a good idea. Hmmm.
--
I will not see posts from Google because I must filter them as spam