Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #30161 > unrolled thread

Java 7 vs 8 speed issues on Win7?

Back to article view | Back to comp.lang.java.programmer

Contents

  Java 7 vs 8 speed issues on Win7? Knute Johnson <eternal@knutejohnson.com> - 2014-10-22 10:18 -0700
    Re: Java 7 vs 8 speed issues on Win7? Silvio <silvio@internet.com> - 2014-10-24 11:10 +0200
    Re: Java 7 vs 8 speed issues on Win7? Roedy Green <see_website@mindprod.com.invalid> - 2014-11-05 04:36 -0800
      Re: Java 7 vs 8 speed issues on Win7? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2014-11-05 08:23 -0800
        Re: Java 7 vs 8 speed issues on Win7? Jan Burse <janburse@fastmail.fm> - 2014-11-05 20:47 +0100
          Re: Java 7 vs 8 speed issues on Win7? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2014-11-05 17:32 -0800
            Re: Java 7 vs 8 speed issues on Win7? Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-11-05 21:37 -0500
              Re: Java 7 vs 8 speed issues on Win7? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2014-11-05 20:00 -0800
                Re: Java 7 vs 8 speed issues on Win7? Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-11-05 23:32 -0500
                  Re: Java 7 vs 8 speed issues on Win7? Robert Klemme <shortcutter@googlemail.com> - 2014-11-06 08:48 +0100
                  Re: Java 7 vs 8 speed issues on Win7? Jan Burse <janburse@fastmail.fm> - 2014-11-06 15:09 +0100
                    Re: Java 7 vs 8 speed issues on Win7? Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-11-06 09:50 -0500
                      Re: Java 7 vs 8 speed issues on Win7? Jan Burse <janburse@fastmail.fm> - 2014-11-06 18:21 +0100
                        Re: Java 7 vs 8 speed issues on Win7? Jan Burse <janburse@fastmail.fm> - 2014-11-06 18:34 +0100
                        Re: Java 7 vs 8 speed issues on Win7? Jan Burse <janburse@fastmail.fm> - 2014-11-06 23:03 +0100
                          Re: Java 7 vs 8 speed issues on Win7? Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-11-06 17:21 -0500
                            Re: Java 7 vs 8 speed issues on Win7? Jan Burse <janburse@fastmail.fm> - 2014-11-07 00:07 +0100
                              Re: Java 7 vs 8 speed issues on Win7? "Bob(but not" THAŢ "Bob)" <nobody@nowhere.net> - 2014-11-07 08:48 +0000
                                Re: Java 7 vs 8 speed issues on Win7? Jan Burse <janburse@fastmail.fm> - 2014-11-08 11:28 +0100
          Re: Java 7 vs 8 speed issues on Win7? Roedy Green <see_website@mindprod.com.invalid> - 2014-11-20 03:12 -0800
            Re: Java 7 vs 8 speed issues on Win7? Silvio <silvio@internet.com> - 2014-11-20 13:24 +0100
              Re: Java 7 vs 8 speed issues on Win7? Robert Klemme <shortcutter@googlemail.com> - 2014-11-20 19:06 +0100
                Re: Java 7 vs 8 speed issues on Win7? Silvio <silvio@internet.com> - 2014-11-20 22:54 +0100
                  Re: Java 7 vs 8 speed issues on Win7? Brixomatic <brixomatic@yahoo.com> - 2014-11-22 08:54 +0100
                    Re: Java 7 vs 8 speed issues on Win7? Brixomatic <brixomatic@yahoo.com> - 2014-11-22 09:19 +0100
      Re: Java 7 vs 8 speed issues on Win7? Fredrik Jonson <fredrik@jonson.org> - 2014-11-29 07:44 +0000

Page 2 of 2 — ← Prev page 1 [2]

#30369

On 11/20/2014 12:12 PM, Roedy Green wrote:
> On Wed, 05 Nov 2014 20:47:18 +0100, Jan Burse <janburse@fastmail.fm>
> wrote, quoted or indirectly quoted someone who said :
>
>> A fundamental change in one of the newer JDKs
>> is a changed semantics for substring(int, int).
>
> see http://mindprod.com/jgloss/substring.html
>
> For a discussion on how the change affects performance.
> For me it is usually negative.
>

My guess is that this is the case for most of the code written prior to 
the change. The semantics where well-known and in the quite specific 
scenario where substrings would hold on to significantly more memory 
than in actual use programmers used one of the many ways to explicitly 
clone them into separate strings. Such code is not affected by the 
change but could be optimized by not doing the extraneous copying.

In other cases code was specifically designed to make good use of the 
semantics as they where. This code will now use significantly more 
memory and do very much extra copying.

I am in the habit of writing lexers and parsers and I still curse the 
day they decided to do this. It was just a cheap way to save memory on 
the String class because it allowed them to ditch the offset/length members.

[toc] | [prev] | [next] | [standalone]

#30370

On 20.11.2014 13:24, Silvio wrote:

> I am in the habit of writing lexers and parsers and I still curse the
> day they decided to do this.

If you want sharing semantics you can still do that by explicitly 
implementing this.  I know, you have to do it which costs.

> It was just a cheap way to save memory on
> the String class because it allowed them to ditch the offset/length
> members.

It's not only that.  I am pretty sure this also has to do with how 
garbage collectors evolved.  Nowadays it is usually much cheaper to just 
create a bunch of short lived objects than trying to devise 
sophisticated schemes to save memory by reusing objects (which then will 
stay around for longer).  And we all know that the longer an object 
lives the higher the GC cost on it because it has to be revisited over 
and over again.  I am pretty confident that engineers at Sun / Oracle 
did sufficient research to warrant the change.  As with every change 
some suffer.  But I assume for the majority it is an improvement or at 
least not noticeable.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#30373

On 11/20/2014 07:06 PM, Robert Klemme wrote:
> It's not only that.  I am pretty sure this also has to do with how
> garbage collectors evolved.  Nowadays it is usually much cheaper to just
> create a bunch of short lived objects than trying to devise
> sophisticated schemes to save memory by reusing objects (which then will
> stay around for longer).  And we all know that the longer an object
> lives the higher the GC cost on it because it has to be revisited over
> and over again.  I am pretty confident that engineers at Sun / Oracle
> did sufficient research to warrant the change.  As with every change
> some suffer.  But I assume for the majority it is an improvement or at
> least not noticeable.

Perhaps, but the GCs where like that for years already.

Additonally, the scenario that an original string becomes very "old" 
because short lived substrings are repeatedly over time created and 
released is relatively rare. Usually either the substrings are 
long-lived (and therefore the original big one is also, in "the old 
way") or they are all short lived allowing the big boy to be collected 
along with them. The old/new thing hardly ever plays a role in the huge 
amount of string-heavy code I have come across.

I suspect memory usage was the primary target. Profilers show that 
strings take up a large part of the memory used by typical applications 
(you should try Eclipse or Netbeans), most of them are very short and 
they contain lots of duplicates. Short strings profit the most from 
dropping the two ints.

The fact that they subsequently added string deduplication to G1 seems 
to support my view. Perhaps this was an optimization that became 
necessary because the new substring creates too many identical 
substrings? I know it does in my parsers, in a big way.

Cheers,

Silvio

>
> Kind regards
>
>      robert
>

[toc] | [prev] | [next] | [standalone]

#30384

In article <546e62ff$0$2978$e4fe514c@news2.news.xs4all.nl>, Silvio 
(silvio@internet.com) says...

> I suspect memory usage was the primary target. Profilers show that 
> strings take up a large part of the memory used by typical applications 
> (you should try Eclipse or Netbeans), most of them are very short and 
> they contain lots of duplicates. Short strings profit the most from 
> dropping the two ints.

Let's stop guessing and read the author of the change:
http://www.reddit.com/comments/1qw73v

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

[toc] | [prev] | [next] | [standalone]

#30385

In article <MPG.2eda5f9093df68eb989695@news.aioe.org>, Brixomatic 
(brixomatic@yahoo.com) says...
> 
> In article <546e62ff$0$2978$e4fe514c@news2.news.xs4all.nl>, Silvio 
> (silvio@internet.com) says...
> 
> > I suspect memory usage was the primary target. Profilers show that 
> > strings take up a large part of the memory used by typical applications 
> > (you should try Eclipse or Netbeans), most of them are very short and 
> > they contain lots of duplicates. Short strings profit the most from 
> > dropping the two ints.
> 
> Let's stop guessing and read the author of the change:
> http://www.reddit.com/comments/1qw73v


More on that topic, extracted from the discussion in the reddit article 
above:

This is from the C# developer on why they do the same:
> http://blogs.msdn.com/b/ericlippert/archive/2011/07/19/strings-
immutability-and-persistence.aspx <

And a related discussion on String#subsequence:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-
February/014609.html

Kind regards,
Wanja



-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

[toc] | [prev] | [next] | [standalone]

#30440

In <ac6k5ahi1h95romsnq52kus20rvbi3psel@4ax.com> Roedy Green wrote:
 
>  I wish there were a switch to get them all dumped for java.exe and
>  javac.exe

I think these flags does what you want.

 java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version

Doesn't seem to be available for javac though.

-- 
Fredrik Jonson

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web