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