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

From: "Dave Cramer" <Dave(at)micro-automation(dot)net>
To: "'Michael Stephenson'" <mstephenson(at)tirin(dot)openworld(dot)co(dot)uk>, "'PostgreSQL jdbc list'" <pgsql-jdbc(at)postgresql(dot)org>
Subject: RE: Re: RE: [ADMIN] High memory usage [PATCH]
Date: 2001-06-26 16:21:38
Message-ID: 001201c0fe5c$13c1d3d0$0201a8c0@INSPIRON
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-jdbc pgsql-patches

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(at)postgresql(dot)org
[mailto:pgsql-jdbc-owner(at)postgresql(dot)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(at)postgresql(dot)org)

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Gunnar Rønning 2001-06-26 16:26:16 Re: Re: RE: [ADMIN] High memory usage [PATCH]
Previous Message Dave Cramer 2001-06-26 16:09:53 RE: High Memory Usage Patch -- Disregard my last message

Browse pgsql-jdbc by date

  From Date Subject
Next Message Gunnar Rønning 2001-06-26 16:26:16 Re: Re: RE: [ADMIN] High memory usage [PATCH]
Previous Message Dave Cramer 2001-06-26 16:09:53 RE: High Memory Usage Patch -- Disregard my last message

Browse pgsql-patches by date

  From Date Subject
Next Message Gunnar Rønning 2001-06-26 16:26:16 Re: Re: RE: [ADMIN] High memory usage [PATCH]
Previous Message Dave Cramer 2001-06-26 16:09:53 RE: High Memory Usage Patch -- Disregard my last message