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: