Re: Re: RE: [ADMIN] High memory usage [PATCH]

> | This won't scale. :o)
>
> Why ? Performance measurements I have seen and also done before has indicated
> that synchronization is faster than the usage of ThreadLocal.

I've just ran a couple of hugely simplified test (basically starting a
couple of thousand threads doing sdf.parse() with either synchronization
or ThreadLocals a couple of times).

With hot spot VM's (I used Sun JDK 1.3.0_02) the difference appears to be
pretty much non existant either way.

With non hot spot VM's (I used Sun JDK 1.2.2) it seems to have a clearer
pattern, the more threads you have the better the ThreadLocal method
performs, and which performs best depends on how many times each Thread
does the format operation (ie how often setDate is called).

For instance with 1000 threads, if they call setDate less than 5 times
the synchronization method seems to be quickest, 5 or more then the
ThreadLocal method performs better.

By the time you have 3000 threads, it only needs to be called 3 times
before the ThreadLocal method becomes quicker. By 5000 threads, if it's
called even twice per thread the syncronization method is 25% slower.

This is fairly inconclusive either way, because clearly different people
use this code in different ways, but I think backs up waht I said about
ThreadLocal's being more scalable, even if they are less efficient in
smaller cases.

I personally would advocate applying a patch similar to below to the
current cvs source.

Michael xxx

--- PreparedStatement.java.orig Tue Jun 26 16:11:16 2001
+++ PreparedStatement.java Tue Jun 26 16:16:26 2001
@@ -44,6 +44,9 @@
private static ThreadLocal tl_df = new ThreadLocal(); // setDate() SimpleDateFormat
private static ThreadLocal tl_tsdf = new ThreadLocal(); // setTimestamp() SimpleDateFormat

+ private SimpleDateFormat sdSdf; // setDate SimpleDateFormat
+ private SimpleDateFormat stSdf; // setTimeStamp SimpleDateFormat
+
/**
* Constructor for the PreparedStatement class.
* Split the SQL statement into segments - separated by the arguments.
@@ -65,13 +68,18 @@
this.sql = sql;
this.connection = connection;

- // might just as well create it here, so we don't take the hit later

- SimpleDateFormat df = new SimpleDateFormat("''yyyy-MM-dd''");
- tl_df.set(df);
-
- df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
- tl_tsdf.set(df);
+ // set up our SimpleDateFormats
+ sdSdf = (SimpleDateFormat)tl_df.get();
+ if (sdSdf == null) {
+ sdSdf = new SimpleDateFormat("''yyyy-MM-dd''");
+ tl_df.set(sdSdf);
+ }
+ stSdf = (SimpleDateFormat)tl_tsdf.get();
+ if (stSdf == null) {
+ stSdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
+ tl_tsdf.set(df);
+ }

for (i = 0; i < sql.length(); ++i)
{
@@ -95,17 +103,6 @@
templateStrings[i] = (String)v.elementAt(i);
}

- /**
- * New in 7.1 - overides Statement.close() to dispose of a few local objects
- */
- public void close() throws SQLException
- {
- // free the ThreadLocal caches
- tl_df.set(null);
- tl_tsdf.set(null);
- super.close();
- }
-
/**
* A Prepared SQL query is executed and its ResultSet is returned
*
@@ -342,9 +339,7 @@
*/
public void setDate(int parameterIndex, java.sql.Date x) throws SQLException
{
- SimpleDateFormat df = (SimpleDateFormat) tl_df.get();
-
- set(parameterIndex, df.format(x));
+ set(parameterIndex, sdSdf.format(x));

// The above is how the date should be handled.
//
@@ -381,13 +376,13 @@
*/
public void setTimestamp(int parameterIndex, Timestamp x) throws SQLException
{
- SimpleDateFormat df = (SimpleDateFormat) tl_tsdf.get();
- df.setTimeZone(TimeZone.getTimeZone("GMT"));
+ stSdf.setTimeZone(TimeZone.getTimeZone("GMT"));

// Use the shared StringBuffer
synchronized(sbuf) {
sbuf.setLength(0);
- sbuf.append("'").append(df.format(x)).append('.').append(x.getNanos()/10000000).append("+00'");
+ sbuf.append("'").append(stSdf.format(x)).append('.')
+ .append(x.getNanos()/10000000).append("+00'");
set(parameterIndex, sbuf.toString());
}