How to tune up this little piece of code?

W

www

Hi,

I am using Eclipse profiler and have found that the following method,
getDate(), in a utility class was called more than 3000 times and cost 5
seconds of accumulative time.

public class Helper //a utility class
{
...//other helping methods

//get the String and return an object of Date
public static Date getDate(String str)
{
Date aDate = null;
if (timeString != null)
{
SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
format.setTimeZone(TimeZone.getTimeZone("UTC"));
try
{
aDate = format.parse(str);
}
catch ... //omitted
}

return aDate;
}
}

I am not very good with code performance. I feel at least something
below should be better:

public class Helper
{
...//other helping methods

private static Date aDate = null;
private static SimpleDateFormat format = (new
SimpleDateFormat("yyyy-MM-dd
HH:mm:ss")).setTimeZone(TimeZone.getTimeZone("UTC"));
public static Date getDate(String str) //now the method is much shorter
{
if (timeString != null)
{
try
{
aDate = format.parse(str);
}
catch ... //omitted
}

return aDate;
}

}

Do you think my new code is legal? Is better?
 
W

www

www said:
Hi,

I am using Eclipse profiler and have found that the following method,
getDate(), in a utility class was called more than 3000 times and cost 5
seconds of accumulative time.

public class Helper //a utility class
{
...//other helping methods

//get the String and return an object of Date
public static Date getDate(String str)
{
Date aDate = null;
if (timeString != null)
{
SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd
HH:mm:ss");
format.setTimeZone(TimeZone.getTimeZone("UTC"));
try
{
aDate = format.parse(str);
}
catch ... //omitted
}

return aDate;
}
}

I am not very good with code performance. I feel at least something
below should be better:

public class Helper
{
...//other helping methods

private static Date aDate = null;
private static SimpleDateFormat format = (new
SimpleDateFormat("yyyy-MM-dd
HH:mm:ss")).setTimeZone(TimeZone.getTimeZone("UTC"));
public static Date getDate(String str) //now the method is much
shorter
{
if (timeString != null)
{
try
{
aDate = format.parse(str);
}
catch ... //omitted
}

return aDate;
}

}

Do you think my new code is legal? Is better?

I just tested the following code. It became worse. It costs 6.3 seconds
now. I am not clear why and why it didn't get better. Thank you very much.

public class Helper
{
...//other helping methods

private static Date aDate = null;
private static SimpleDateFormat format = new
SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
public static Date getDate(String str) //now the method is much
shorter
{
if (timeString != null)
{
try
{
format.setTimeZone(TimeZone.getTimeZone("UTC"))
aDate = format.parse(str);
}
catch ... //omitted
}

return aDate;
}

}
 
O

Oliver Wong

www said:
Hi,

I am using Eclipse profiler and have found that the following method,
getDate(), in a utility class was called more than 3000 times and cost 5
seconds of accumulative time.

public class Helper //a utility class
{
...//other helping methods

//get the String and return an object of Date
public static Date getDate(String str)
{
Date aDate = null;
if (timeString != null)
{
SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
format.setTimeZone(TimeZone.getTimeZone("UTC"));
try
{
aDate = format.parse(str);
}
catch ... //omitted
}

return aDate;
}
}

I am not very good with code performance. I feel at least something below
should be better:

public class Helper
{
...//other helping methods

private static Date aDate = null;
private static SimpleDateFormat format = (new SimpleDateFormat("yyyy-MM-dd
HH:mm:ss")).setTimeZone(TimeZone.getTimeZone("UTC"));
public static Date getDate(String str) //now the method is much shorter
{
if (timeString != null)
{
try
{
aDate = format.parse(str);
}
catch ... //omitted
}

return aDate;
}

}

Do you think my new code is legal? Is better?

The old code will return null when passed in null. The new code will
return the previously parsed date when passed in null.

- Oliver
 
M

Michael

I am not very good with code performance. I feel at least something
below should be better:

public class Helper
{
...//other helping methods

private static Date aDate = null;
private static SimpleDateFormat format = (new
SimpleDateFormat("yyyy-MM-dd
HH:mm:ss")).setTimeZone(TimeZone.getTimeZone("UTC"));
public static Date getDate(String str) //now the method is much shorter
{
if (timeString != null)
{
try
{
aDate = format.parse(str);
}
catch ... //omitted
}

return aDate;
}

}

Do you think my new code is legal? Is better?

aDate shouldn't be static. Only 'format' should be. 'aDate' should be
a local variable in getDate
 
D

Daniel Pitts

www said:
Hi,

I am using Eclipse profiler and have found that the following method,
getDate(), in a utility class was called more than 3000 times and cost 5
seconds of accumulative time.
[snip]
5 seconds of accumulative time, compared to what lifecycle? If it takes
5 seconds out of an hour, then its not worth worrying about. It also be
worth looking at what client code calls it, and see if they call it
unnecessarily. Parsing a date isn't a very cheap operation, so if you
can avoid repeating it, that might help.
 
T

Thomas Fritsch

www said:
I am not very good with code performance. I feel at least something
below should be better:

public class Helper
{
...//other helping methods

private static Date aDate = null;
private static SimpleDateFormat format = (new
SimpleDateFormat("yyyy-MM-dd
HH:mm:ss")).setTimeZone(TimeZone.getTimeZone("UTC"));
The above 3 lines are syntactically wrong because setTimeZone(...)
returns void, and hence can't be assigned to format.
You probably want:
private static SimpleDateFormat format;
static
{
// This code is executed once when the class is loaded.
format = (new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));
format.setTimeZone(TimeZone.getTimeZone("UTC"));
}
 
W

www

Thomas said:
The above 3 lines are syntactically wrong because setTimeZone(...)
returns void, and hence can't be assigned to format.
You probably want:
private static SimpleDateFormat format;
static
{
// This code is executed once when the class is loaded.
format = (new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));
format.setTimeZone(TimeZone.getTimeZone("UTC"));
}

Thank you very much. With the your code, the performance is much improved.

I am still unclear. Can I move Date aDate to be outside of the method?
Right now, I leave it as local variable inside the method? Somebody said
previously that I must leave it as local variable. But I am not clear why.
 
T

Tom Hawtin

If you have trouble with some code, it's best to post compilable code.

From SimpleDateFormat: "Date formats are not synchronized. It is
recommended to create separate format instances for each thread. If
multiple threads access a format concurrently, it must be synchronized
externally."

So it's not legal. If you were to go down this route, you should either
use synchronized, ThreadLocal, AtomicReference or similar. (Even if you
didn't make a mess of the date variable.)
I just tested the following code. It became worse. It costs 6.3 seconds
now. I am not clear why and why it didn't get better. Thank you very much.

Presumably constructing the date format is not expensive as parsing the
date (even if you didn't play about with the time zone each iteration).

Tom Hawtin
 
L

Lew

www said:
I am still unclear. Can I move Date aDate to be outside of the method?
Right now, I leave it as local variable inside the method? Somebody said
previously that I must leave it as local variable. But I am not clear why.

If it is outside the method as an instance or static variable, it is only one
object that is altered and reported by different code. It saves you nothing,
because you construct a Date inside the method anyway, but it does cause risk
of collision between different clients of the Date object. If you expect the
Date in a client module to remain unchanged, you might be surprised.

If you assign a local variable to point to the new Date, you are giving each
client a separate Date reference that is immune to others' use.

Which behavior do you require?

- Lew
 
D

Daniel Pitts

Lew said:
If it is outside the method as an instance or static variable, it is only one
object that is altered and reported by different code. It saves you nothing,
because you construct a Date inside the method anyway, but it does cause risk
of collision between different clients of the Date object. If you expect the
Date in a client module to remain unchanged, you might be surprised.

If you assign a local variable to point to the new Date, you are giving each
client a separate Date reference that is immune to others' use.

Which behavior do you require?

- Lew
Not to mention what happens in multi-threaded environements!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,994
Messages
2,570,223
Members
46,812
Latest member
GracielaWa

Latest Threads

Top