RE: Re: RE: [ADMIN] High memory usage [PATCH] - Mailing list pgsql-jdbc

From Dave Cramer
Subject RE: Re: RE: [ADMIN] High memory usage [PATCH]
Date
Msg-id 001201c0fe5c$13c1d3d0$0201a8c0@INSPIRON
Whole thread Raw
In response to Re: Re: RE: [ADMIN] High memory usage [PATCH]  (Michael Stephenson <mstephenson@tirin.openworld.co.uk>)
List pgsql-jdbc
Michael,

Barry pointed out that it isn't necessary for the constructor to be
called from the same thread that is accessing the SimpleDateFormat
objects. I think this requires the test to be done when the objects are
being accessed?

Dave

-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org
[mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Michael Stephenson
Sent: June 26, 2001 11:21 AM
To: 'PostgreSQL jdbc list'; Gunnar Rønning
Subject: Re: [JDBC] 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()/10
000000).append("+00'");
+            sbuf.append("'").append(stSdf.format(x)).append('.')
+        .append(x.getNanos()/10000000).append("+00'");
             set(parameterIndex, sbuf.toString());
           }




---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)



pgsql-jdbc by date:

Previous
From: Gunnar Rønning
Date:
Subject: Re: RE: [ADMIN] High memory usage [PATCH]
Next
From: Gunnar Rønning
Date:
Subject: Re: Re: RE: [ADMIN] High memory usage [PATCH]