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

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

java8 up to 6x slower than java7

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

Contents

  java8 up to 6x slower than java7 Dennis Haupt <d.haupt82@gmail.com> - 2014-02-15 03:00 -0800
    Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-02-15 12:26 +0100
      Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-02-15 12:28 +0100
      Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-02-15 12:52 +0100
        Re: java8 up to 6x slower than java7 Robert Klemme <shortcutter@googlemail.com> - 2014-02-16 13:10 +0100
          Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-02-16 14:38 +0100
            Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-02-16 14:43 +0100
              Re: java8 up to 6x slower than java7 Robert Klemme <shortcutter@googlemail.com> - 2014-02-16 14:53 +0100
                Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-02-16 20:27 +0100
                  Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-02-16 20:36 +0100
                    Re: java8 up to 6x slower than java7 Robert Klemme <shortcutter@googlemail.com> - 2014-02-17 18:55 +0100
                      Re: java8 up to 6x slower than java7 Wanja Gayk <brixomatic@yahoo.com> - 2014-03-02 20:52 +0100
                        Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-03-03 11:53 +0100
                          Re: java8 up to 6x slower than java7 Joerg Meier <joergmmeier@arcor.de> - 2014-03-03 17:16 +0100
                            Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-03-03 19:53 +0100
                            Re: java8 up to 6x slower than java7 Lew <lewbloch@gmail.com> - 2014-03-03 13:44 -0800
        Re: java8 up to 6x slower than java7 Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2014-02-16 11:24 -0800
    Re: java8 up to 6x slower than java7 Robert Klemme <shortcutter@googlemail.com> - 2014-02-15 12:55 +0100
    Re: java8 up to 6x slower than java7 "Qu0ll" <Qu0llSixFour@gmail.com> - 2014-02-15 23:42 +1100
    Re: java8 up to 6x slower than java7 Roedy Green <see_website@mindprod.com.invalid> - 2014-02-16 00:25 -0800

#27512 — java8 up to 6x slower than java7

i wrote a little pathfinder. i can run it under the jdk7 update 51 and it is done in ~20 seconds. under java8, since a long series of builds, a certain part involving deeeeeeeeeep recursion takes ~60 seconds instead of 10.
i suspected the hashmap change of java8 to be the culprit since i perform a lot of put operations, but that's not it - i used the standard  hashmap from scala to be 100% sure the hashmap can't be the reason (or is), and indeed, i get the same performance difference between java7 and 8 with the same hashmap
my profiler (yourkit) shows that java8 spends a much bigger amount of time on garbage collection and allocated more objects. if i take a memory snapshot, can see that the final results are equal, so i have more temporary objects. yourkit also shows that more objects are allocated using java8.
what is up with that?
all i do in the critical method is creating arraylists and performing puts, contains and gets on a hashmap, and the recursive call. the time is, according to yourkit, spend in the method itself, not inside the hashmap or arraylist constructor.
any ideas?

[toc] | [next] | [standalone]

#27513

Dennis Haupt schrieb:
> i wrote a little pathfinder. i can run it under the jdk7 update 51 and it is done in ~20 seconds. under java8, since a long series of builds, a certain part involving deeeeeeeeeep recursion takes ~60 seconds instead of 10.
> i suspected the hashmap change of java8 to be the culprit since i perform a lot of put operations, but that's not it - i used the standard  hashmap from scala to be 100% sure the hashmap can't be the reason (or is), and indeed, i get the same performance difference between java7 and 8 with the same hashmap
> my profiler (yourkit) shows that java8 spends a much bigger amount of time on garbage collection and allocated more objects. if i take a memory snapshot, can see that the final results are equal, so i have more temporary objects. yourkit also shows that more objects are allocated using java8.
> what is up with that?
> all i do in the critical method is creating arraylists and performing puts, contains and gets on a hashmap, and the recursive call. the time is, according to yourkit, spend in the method itself, not inside the hashmap or arraylist constructor.
> any ideas?
>

I found that JDK 8 is more speedier than JDK 7, around 5%
better, which is nice. But my testing might not be
representative:

     Jekejeke Prolog Runtime on JDK 8
     https://plus.google.com/103259555581227445618/posts/Mjw49qhBWku

I didn't yet have a closer look to one of my apps. Usually
I also look how the IDE behaves. But unfortunately IntelliJ
IDEA 13 refuses to run under JDK 8 as of now. Didn't yet
figure out how to start it with JDK 8. Compiling JDK 8
on the other works fine.

Bye

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

#27514

Jan Burse schrieb:
> I found that JDK 8 is more speedier than JDK 7, around 5%
> better, which is nice. But my testing might not be
> representative:

But I somehow have the feeling that the JIT is slower.
It took me more iteration until I had a warm run,
where all the JIT has kicked in.

Bye

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

#27516

Jan Burse schrieb:
> i wrote a little pathfinder. i can run it under the jdk7 update 51 and
> it is done in ~20 seconds. under java8, since a long series of builds, a
> certain part involving deeeeeeeeeep recursion takes ~60 seconds instead
> of 10.
> i suspected the hashmap change of java8 to be the culprit since i
> perform a lot of put operations, but that's not it - i used the
> standard  hashmap from scala to be 100% sure the hashmap can't be the
> reason (or is), and indeed, i get the same performance difference
> between java7 and 8 with the same hashmap
> my profiler (yourkit) shows that java8 spends a much bigger amount of
> time on garbage collection and allocated more objects. if i take a
> memory snapshot, can see that the final results are equal, so i have
> more temporary objects. yourkit also shows that more objects are
> allocated using java8.
> what is up with that?
> all i do in the critical method is creating arraylists and performing
> puts, contains and gets on a hashmap, and the recursive call. the time
> is, according to yourkit, spend in the method itself, not inside the
> hashmap or arraylist constructor.
> any ideas?

I must admit that I don't use the Java hashmap and have written
a custom version. The reason for this custom version was basically
to allow faster iteration, and not allocating an iterator. This
was already done before JDK 8 came out, independent of JDK 8.

But I now read that JDK 8 has introduced a new realization
of HashMap. See for example:

 
http://blog.credera.com/technology-insights/java/java-8-part-3-hashmap-java-time/

So I understand that you could see dramatic negative changes.
Sorry to hear that.

I will check my code more closely now, and try to eliminate more
of HashMap by my custom code where appropriate.

Bye

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

#27524

On 15.02.2014 12:52, Jan Burse wrote:

> I must admit that I don't use the Java hashmap and have written
> a custom version. The reason for this custom version was basically
> to allow faster iteration, and not allocating an iterator. This
> was already done before JDK 8 came out, independent of JDK 8.

I also once wrote a Map using double Hashing.  The reason at the time 
was to avoid the many Entry instances.  But we did only replace certain 
uses of HashMap which we knew would create and GC lots of Entry 
instances and have rare iterations (Entry instances were created during 
iteration only, this was the downside).

> But I now read that JDK 8 has introduced a new realization
> of HashMap. See for example:
>
> http://blog.credera.com/technology-insights/java/java-8-part-3-hashmap-java-time/

How is this supposed to work for keys which do not implement Comparable? 
  Or are they using the hash code only for the tree arrangement?  Also, 
the article does not mention that the fill factor limits the average 
length of the chain used for linear probing.

It's also not mentioned in the article how they create the tree.  You 
can use an object per node but you can sometimes also use an array.

> So I understand that you could see dramatic negative changes.
> Sorry to hear that.

I am surprised that they do such a dramatic change to a standard library 
class.  In the past Sun / Oracle seemed to always try to minimize the 
impact on programs.

> I will check my code more closely now, and try to eliminate more
> of HashMap by my custom code where appropriate.

I would first do some analysis before going there to determine how long 
linear probing is on average.

Kind regards

	robert

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

#27525

Robert Klemme schrieb:
> Also, the article does not mention that the fill factor limits the
> average length of the chain used for linear probing.

Yes, that is also my idea. I guess the problem is bound
to bad hashing in the objects that are used as keys, or
hashing that remains konstant even when the fill factor
changes.

I wonder why the web server or any of the business cases
that need that improvement do not implement a combination
uf HashMap and TreeMap by themselfs, so as to leave the
HashMap a more primitive construct.

The source code of the new HashMap is found in the
early access distribution of JDK 8. It seems that
they use a constant threshold:

    static final int MIN_TREEIFY_CAPACITY = 64;

And then there is a lot of copying and creating new
objects going on:

    final void treeify(Node<K,V>[] tab) {

And the tree seems to be sorted first by the hash
and by compareTo(). Whereby they use reflection to
figure out whether one of the objects implements the
generic interface.

I guess the above can lead to performance degradation,
especially in border cases, for example when one
unitentionally runs into the treeification but then
doesn't make much use of it.

Maybe for non border cases, the new HashMap is ok,
probably a bigger memory foot print. I made some
application tests over the last days. 1 use case is
faster, and 2 use cases are slower.

For the slower use cases I am planing using my custom
HashMap. The custom HashMap has some further advantages
besides sparing the iterator, I also don't do mod
counting.

One trick to develop a custom HashMap is to use the
JDK source code, and create a stripped down variant.
Not sure whether copyright allows this really. So I
didn't mention that here.

Bye

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

#27526

Jan Burse schrieb:
> For the slower use cases I am planing using my custom
> HashMap. The custom HashMap has some further advantages
> besides sparing the iterator, I also don't do mod
> counting.

Last but not least, one feature I am constantly missing
from HashMap, is that it should grow back in size.
HashMap is only growing and growing, and never
automatically shrinks.

> One trick to develop a custom HashMap is to use the
> JDK source code, and create a stripped down variant.
> Not sure whether copyright allows this really. So I
> didn't mention that here.

The shrinking I didn't find in the JDK source code,
so this is genuine implementation. I use a lower
watermark which is 1/4 and I am shrinking to 1/2.
Works pretty well so far.

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

#27527

On 16.02.2014 14:43, Jan Burse wrote:
> Jan Burse schrieb:
>> For the slower use cases I am planing using my custom
>> HashMap. The custom HashMap has some further advantages
>> besides sparing the iterator, I also don't do mod
>> counting.
>
> Last but not least, one feature I am constantly missing
> from HashMap, is that it should grow back in size.
> HashMap is only growing and growing, and never
> automatically shrinks.

Usually there is good reason to not do this: if a long lived collection 
reaches a particular size at some point in time chances are that it will 
do so in the future again.  Shrinking will cause allocation overhead and 
- at a later point - another allocation for the larger size which has 
higher risk of causing slow GC because of memory fragmentation.  Also, 
if the long lived collection resizes internally at least for some GC 
cycles there is a reference from old gen to new gen.

For short lived objects additional allocations to save memory are even 
worse.  There it's usually best to just grow.

For the long lived case you can still manually shrink by creating a new 
collection if the nature of your application is such that there 
temporarily the collection grows huge and afterwards shrinks again.

Kind regards

	robert

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

#27531

Hi,

Robert Klemme schrieb:
> For the long lived case you can still manually shrink by creating a new
> collection if the nature of your application is such that there
> temporarily the collection grows huge and afterwards shrinks again.

You have this effect and can control this effect by an appropriate
lower water mark choice. Without putting some special compaction
points into your code. Overhead is only a compare instruction
besides the compaction itself.

It should be noted that you are true, that the compaction is not
necessary. It does even make the hashing less good, since you
have fewer bins. Normally a hash map that grows and grows, will
nevertheless have smaller bin lengths when elements are
removed again.

Main reason I opted for automatic compaction of my hash maps was
that my application has miriads of hash maps. Well not miriads,
but a lot of hash maps. They are used for some just in time indexing,
and are even recursively built, i.e. hash values that are again hash 
maps and so.

So the requirement was really to have very light weighted hash
maps for this data structure. Even if there is a small time overhead.
Problem was that application crashed without compaction, since
memory consumption was too high.

Bye

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

#27532

Jan Burse schrieb:
> So the requirement was really to have very light weighted hash
> maps for this data structure. Even if there is a small time overhead.
> Problem was that application crashed without compaction, since
> memory consumption was too high.

The requirement is that the following code should
eat up O(m) space and not O(m*n) space:

   HashMap[] maps = new HashMap[m];
   for (int i=0; i<m; i++) {
      maps = new HashMap();
   }
   for (int i=0; i<m; i++) {
      for (int j=0; j<n; i++) {
         maps[i].put(j,j)
      }
      for (int j=0; j<n; i++) {
         maps[i].remove(j);
      }
   }

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

#27534

On 16.02.2014 20:36, Jan Burse wrote:
> Jan Burse schrieb:
>> So the requirement was really to have very light weighted hash
>> maps for this data structure. Even if there is a small time overhead.
>> Problem was that application crashed without compaction, since
>> memory consumption was too high.
>
> The requirement is that the following code should
> eat up O(m) space and not O(m*n) space:
>
>    HashMap[] maps = new HashMap[m];
>    for (int i=0; i<m; i++) {
>       maps = new HashMap();
>    }
>    for (int i=0; i<m; i++) {
>       for (int j=0; j<n; i++) {
>          maps[i].put(j,j)
>       }
>       for (int j=0; j<n; i++) {
>          maps[i].remove(j);
>       }
>    }

What is n here?  Is that some arbitrary input figure otherwise unrelated 
to the shown code?

A small change which would help this code and avoid too much overhead is 
to set the table to null once the Map is empty.  Since all your Maps are 
empty at the end this would help dramatically.

Cheers

	robert

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

#27654

In article <bmf0noFpsoqU1@mid.individual.net>, Robert Klemme 
(shortcutter@googlemail.com) says...

> >> So the requirement was really to have very light weighted hash
> >> maps for this data structure. Even if there is a small time overhead.
> >> Problem was that application crashed without compaction, since
> >> memory consumption was too high.

[..]

> A small change which would help this code and avoid too much overhead 
is 
> to set the table to null once the Map is empty.  Since all your Maps are 
> empty at the end this would help dramatically.

I'd say it's hard to help Jan, if he doesn't provide some real code with 
some "real" (or generated) data to chew on.

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]

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

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

#27659

Wanja Gayk schrieb:
> I'd say it's hard to help Jan, if he doesn't provide some real code with
> some "real" (or generated) data to chew on.

Well better help Dennis Haupt, not me, the original poster
of the thread.

Me myself is anyway a hopeless case. I just discovered
ConcurrentHashMap in JDK 8. Very interesting, it doesn't
use a lock on the outside, but I counted 9 times a
synchronized statement inside the code.

Still thinking about what the implications of
ConcurrentHashMap could be for my further development.

Also I stuck with the following problem:
http://stackoverflow.com/questions/22135449/maintaining-unique-objects-for-names-with-concurrent-delete

Bye

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

#27666

On Mon, 03 Mar 2014 11:53:41 +0100, Jan Burse wrote:

> Me myself is anyway a hopeless case. I just discovered
> ConcurrentHashMap in JDK 8. Very interesting, it doesn't
> use a lock on the outside, but I counted 9 times a
> synchronized statement inside the code.

From
<http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ConcurrentHashMap.html>

Since:
    1.5
    
Not exactly new ;)

As for your problem, I didn't quite understand your problem description,
but just in case you aren't aware, you don't have to synchronize on the
object you deal with in the block - you can synchronize on anything you
want, and many people use a helper field like 

private final Object $LOCK = new Object();

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

#27673

Hi,

It seems to me that the ConcurrentHashMap of JDK 8
adopts the tree structure for lage bins already
found in the HashMap of JDK 8. Namely I find:

    ConcurrentHashMap JDK 5:
        No method treeifyBin in source code found.
        (Related to this thread, i.e. is JDK 8 slower?)
        No method computeIfAbsent in source code found.
        (Not directly related, but also interesting)

    ConcurrentHashMap JDK 8:
        A method treeifyBin in source code found.
        (Related to this thread, i.e. is JDK 8 slower?)
        A method computeIfAbsent in source code found.
        (Not directly related, but also interesting,
         see also: 
http://stackoverflow.com/questions/19278443/how-do-i-use-the-new-computeifabsent-function)

Since ConcurrentHashMap uses more effectively inner
locks, I will destroy all this efficiency when I
use an outer lock.

This is my concern when I would use the concurrent
hash map as follows:

     synchronized(map) {
         /* do more than one operation on map,
            atomically */
     }

This concern also holds if I use as an extra lock
for example:

     public final lock = new Object();

     synchronized(lock) {
         /* do more than one operation on map,
            atomically */
     }

The only benefit respectively drawback of the
extra lock is that more memory is used.

But nevertheless the pattern of an extra lock
is often seen for various reasons.

Bye

Joerg Meier schrieb:
> On Mon, 03 Mar 2014 11:53:41 +0100, Jan Burse wrote:
>
>> Me myself is anyway a hopeless case. I just discovered
>> ConcurrentHashMap in JDK 8. Very interesting, it doesn't
>> use a lock on the outside, but I counted 9 times a
>> synchronized statement inside the code.
>
> From
> <http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ConcurrentHashMap.html>
>
> Since:
>      1.5
>
> Not exactly new ;)
>
> As for your problem, I didn't quite understand your problem description,
> but just in case you aren't aware, you don't have to synchronize on the
> object you deal with in the block - you can synchronize on anything you
> want, and many people use a helper field like
>
> private final Object $LOCK = new Object();
>
> Liebe Gruesse,
> 		Joerg
>

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

#27678

On Monday, March 3, 2014 8:16:21 AM UTC-8, Joerg Meier wrote:
> private final Object $LOCK = new Object();

That violates the coding conventions in both the Coding Conventions document and the JLS:

http://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.8 
"The $ character should be used only in mechanically generated source code or, 
rarely, to access pre-existing names on legacy systems."

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099.html#367 
"Variable names should not start with underscore _ or dollar sign $ characters, 
even though both are allowed."

-- 
Lew

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

#27530

In article <ldnkf1$pp0$1@news.albasani.net>,
 Jan Burse <janburse@fastmail.fm> wrote:

> Jan Burse schrieb:
> > i wrote a little pathfinder. i can run it under the jdk7 update 51 and
> > it is done in ~20 seconds. under java8, since a long series of builds, a
> > certain part involving deeeeeeeeeep recursion takes ~60 seconds instead
> > of 10.
> > i suspected the hashmap change of java8 to be the culprit since i
> > perform a lot of put operations, but that's not it - i used the
> > standard  hashmap from scala to be 100% sure the hashmap can't be the
> > reason (or is), and indeed, i get the same performance difference
> > between java7 and 8 with the same hashmap
> > my profiler (yourkit) shows that java8 spends a much bigger amount of
> > time on garbage collection and allocated more objects. if i take a
> > memory snapshot, can see that the final results are equal, so i have
> > more temporary objects. yourkit also shows that more objects are
> > allocated using java8.
> > what is up with that?
> > all i do in the critical method is creating arraylists and performing
> > puts, contains and gets on a hashmap, and the recursive call. the time
> > is, according to yourkit, spend in the method itself, not inside the
> > hashmap or arraylist constructor.
> > any ideas?
> 
> I must admit that I don't use the Java hashmap and have written
> a custom version. The reason for this custom version was basically
> to allow faster iteration, and not allocating an iterator. This
> was already done before JDK 8 came out, independent of JDK 8.
> 
> But I now read that JDK 8 has introduced a new realization
> of HashMap. See for example:
> 
>  
> http://blog.credera.com/technology-insights/java/java-8-part-3-hashmap-java-ti
> me/
> 
> So I understand that you could see dramatic negative changes.
> Sorry to hear that.
> 
> I will check my code more closely now, and try to eliminate more
> of HashMap by my custom code where appropriate.
> 
> Bye


Wow, that sounds like an intense optimization, though I can't find the 
source code online to see it.  Much like the String change, it's going 
to have cases where performance becomes extremely bad.

As for profiling - don't trust it for small bits of code.  Sampling can 
only see safepoints, and instrumentation breaks local optimizations.  My 
favorite glitch is that Integer.hash(), which contains no code, turns up 
as a top hot spot in some of my code.  It's actually the caller eating 
CPU time but that's not seen by any profiler.

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

#27517

On 15.02.2014 12:00, Dennis Haupt wrote:
> i wrote a little pathfinder. i can run it under the jdk7 update 51
> and it is done in ~20 seconds. under java8, since a long series of
> builds, a certain part involving deeeeeeeeeep recursion takes ~60
> seconds instead of 10. i suspected the hashmap change of java8 to be
> the culprit since i perform a lot of put operations, but that's not
> it - i used the standard  hashmap from scala to be 100% sure the
> hashmap can't be the reason (or is), and indeed, i get the same
> performance difference between java7 and 8 with the same hashmap my
> profiler (yourkit) shows that java8 spends a much bigger amount of
> time on garbage collection and allocated more objects. if i take a
> memory snapshot, can see that the final results are equal, so i have
> more temporary objects. yourkit also shows that more objects are
> allocated using java8. what is up with that? all i do in the critical
> method is creating arraylists and performing puts, contains and gets
> on a hashmap, and the recursive call. the time is, according to
> yourkit, spend in the method itself, not inside the hashmap or
> arraylist constructor. any ideas?

Does your profiler not show allocation hotspots?  Other than that it's 
just wild speculation without seeing the code.

Cheers

	robert

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

#27519

"Dennis Haupt"  wrote in message 
news:29a51a94-8f9a-41b1-980f-e8c13e2d11a2@googlegroups.com...

-------------------------
i wrote a little pathfinder. i can run it under the jdk7 update 51 and it is 
done in ~20 seconds. under java8, since a long series of builds, a certain 
part involving deeeeeeeeeep recursion takes ~60 seconds instead of 10.
i suspected the hashmap change of java8 to be the culprit since i perform a 
lot of put operations, but that's not it - i used the standard  hashmap from 
scala to be 100% sure the hashmap can't be the reason (or is), and indeed, i 
get the same performance difference between java7 and 8 with the same 
hashmap
my profiler (yourkit) shows that java8 spends a much bigger amount of time 
on garbage collection and allocated more objects. if i take a memory 
snapshot, can see that the final results are equal, so i have more temporary 
objects. yourkit also shows that more objects are allocated using java8.
what is up with that?
all i do in the critical method is creating arraylists and performing puts, 
contains and gets on a hashmap, and the recursive call. the time is, 
according to yourkit, spend in the method itself, not inside the hashmap or 
arraylist constructor.
any ideas?
------------------------------

Which GC are you using?
Have you tried some of the new options?
Have you tried tuning GC at all?

Perhaps the default GC or GC configurations have changed?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me] 

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

#27521

On Sat, 15 Feb 2014 03:00:43 -0800 (PST), Dennis Haupt
<d.haupt82@gmail.com> wrote, quoted or indirectly quoted someone who
said :

>any ideas?

what did you configure for memory pool size in each?

A benchmark should "warm up" for a while before its starts timing.

They may differ when they take time out to generate machine code, or
how much time they spend optimising it.

Java 8 is not released yet. It may contain all kinds of debug code
that will be stripped for release.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The future has already happened, it just isn’t evenly distributed.
~ William Gibson (born: 1948-03-17 age: 65)

[toc] | [prev] | [standalone]

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

csiph-web