Warnings Cleanup in java.util. (more from hack day) (original) (raw)
Xueming Shen xueming.shen at oracle.com
Fri Dec 2 15🔞03 PST 2011
- Previous message: Warnings Cleanup in java.util. (more from hack day)
- Next message: Warnings Cleanup in java.util. (more from hack day)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 12/02/2011 02:32 PM, Martijn Verburg wrote:
Hi Sherman,
I think the original patch provider (Prasanna) was aiming at simply removing the deprecation warning. Interesting point on the performance aspect! Is performance for this class already measured in an OpenJDK test somewhere? Perhaps we could provide a test suite in this instance?
Hi Martijn,
No, I don't think we have a benchmark test case anywhere in OpenJDK to measure this performance. I happened to take a quick look at the "calculation cost" of dosToJavaTime() last month when working on that jar n-thread performance issue.
Here is a the result of a quick/dirty "non-benchmark" benchmark test case, which suggests the proposed change is way too slow, this is only from the "speed" angle, I would assume it probably also consumes more temporary (young-gen) memory. So, the suggested approach appears not to be a good candidate to go in without further tuning.
sherman at sherman-linux:/Workspace/test$ java -server JavaDosTime
j2dt :386
j2dt2 :1282
d2jt :424
d2jt2 :1296
sherman at sherman-linux:/Workspace/test$ java -client JavaDosTime
j2dt :621
j2dt2 :1901
d2jt :662
d2jt2 :2016
public class JavaDosTime {
public static void main(String[] args) throws IOException {
long tt0 = System.currentTimeMillis();
int ii = 0;
for (ii = 0; ii < 1000000; ii++) {
long t = 10000 + ii;
t= javaToDosTime(t);
}
long tt1 = System.currentTimeMillis();
System.out.println("j2dt :" + (tt1 - tt0));
tt0 = System.currentTimeMillis();
ii = 0;
for (ii = 0; ii < 1000000; ii++) {
long t = 10000 + ii;
t= javaToDosTime2(t);
}
tt1 = System.currentTimeMillis();
System.out.println("j2dt2 :" + (tt1 - tt0));
tt0 = System.currentTimeMillis();
ii = 0;
for (ii = 0; ii < 1000000; ii++) {
long t = 10000 + ii;
t= dosToJavaTime(t);
}
tt1 = System.currentTimeMillis();
System.out.println("d2jt :" + (tt1 - tt0));
tt0 = System.currentTimeMillis();
ii = 0;
for (ii = 0; ii < 1000000; ii++) {
long t = 10000 + ii;
t= dosToJavaTime2(t);
}
tt1 = System.currentTimeMillis();
System.out.println("d2jt2 :" + (tt1 - tt0));
}
private static long javaToDosTime(long time){
Date d = new Date(time);
int year = d.getYear() + 1900;
if (year < 1980) {
return (1 << 21) | (1 << 16);
}
return (year - 1980) << 25 | (d.getMonth() + 1) << 21 |
d.getDate() << 16 | d.getHours() << 11 | d.getMinutes()
<< 5 | d.getSeconds() >> 1; }
private static long javaToDosTime2(long time){
Calendar cal = Calendar.getInstance();
cal.setTimeInMillis(time);
int year = cal.get(Calendar.YEAR);
if (year < 1980) {
return (1 << 21) | (1 << 16);
}
int month = cal.get(Calendar.MONTH) + 1;
return (year - 1980) << 25
| month << 21
| cal.get(Calendar.DAY_OF_MONTH) << 16
| cal.get(Calendar.HOUR_OF_DAY) << 11
| cal.get(Calendar.MINUTE) << 5
| cal.get(Calendar.SECOND) >> 1;
}
private static long dosToJavaTime(long dtime) {
Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
(int)(((dtime >> 21) & 0x0f) - 1),
(int)((dtime >> 16) & 0x1f),
(int)((dtime >> 11) & 0x1f),
(int)((dtime >> 5) & 0x3f),
(int)((dtime << 1) & 0x3e));
return d.getTime();
}
private static long dosToJavaTime2(long dtime) {
Calendar cal = Calendar.getInstance();
cal.set(Calendar.YEAR, (int) ((dtime >> 25) & 0x7f) + 1980);
cal.set(Calendar.MONTH, (int) ((dtime >> 21) & 0x0f) - 1);
cal.set(Calendar.DATE, (int) (dtime >> 16) & 0x1f);
cal.set(Calendar.HOUR_OF_DAY, (int) (dtime >> 11) & 0x1f);
cal.set(Calendar.MINUTE, (int) (dtime >> 5) & 0x3f);
cal.set(Calendar.SECOND, (int) (dtime << 1) & 0x3e);
return cal.getTimeInMillis();
}
}
Cheers, Martijn On Friday, 2 December 2011, Xueming Shen <xueming.shen at oracle.com_ _<mailto:xueming.shen at oracle.com>> wrote: > > The j.u.z.ZipEntry change should NOT be in as a warning cleanup. Will need further > evaluation/measurement, for example from performance point of view, the change > now creates a new Calendar instance instead of a Date object (Date class uses a > singleton BaseCalendar for the calculation, if I remember correctly) for each invocation. > > -Sherman > > On 12/02/2011 11:24 AM, Michael Barker wrote: >> >> Hi, >> >> We had some late submissions from our hack day participants. 2 more >> patches. One (j.u.z.ZipEntry) is possibly a little more involved for >> a warnings fix. It removes a usage of deprecated Date APIs in favour >> of Calendar. However, the fix results in code that is very similar to >> Apache Harmony implementation. The other is a couple of fixes for >> generics (j.u.j.Manifest). >> >> Thanks to: >> - Prasannaa >> >> Regards, >> Michael Barker >> mikeb2701 > >
- Previous message: Warnings Cleanup in java.util. (more from hack day)
- Next message: Warnings Cleanup in java.util. (more from hack day)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]