ECJ-INTEREST-L Archives

February 2006

ECJ-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Chris Ellingwood <[log in to unmask]>
Reply To:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Date:
Mon, 6 Feb 2006 19:02:13 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (20 lines)
Hi Sean, 

  That's an interesting difference between our performance measurements.

  You wrote:
---
Note that 38% of the time is spent in GC; but allocation isn't that  
bad at all, at least with Xprof.  new array millicode is only 1.2%   
The big kahuna in allocation is clone(), which clocks in at 21.7% (up  
from 11.4% in Java 1.3.1).  This *should* basically boil down to a  
pointer increment and a memcpy.  (As opposed to new object(), which  
is a pointer increment and a bzero).  What I think is happening is  
that the cost of other elements are being optimized out in successive  
Java versions, so allocation is becoming more costly relative to them.
---
  
  An alternative explanation is that my inline performance measurements 
are not as accurate as the -XProf. The new array allocation may trigger 
some form of GC and my measurement is including the time involved for GC. 

ATOM RSS1 RSS2