Re: Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems

From: Peter Mount <peter(at)retep(dot)org(dot)uk>
To: Michael Stephenson <mstephenson(at)tirin(dot)openworld(dot)co(dot)uk>, PostgreSQL jdbc list <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems
Date: 2001-01-30 23:25:06
Message-ID: 5.0.2.1.0.20010130232320.009f7570@mail.retep.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces pgsql-jdbc pgsql-patches

At 09:39 30/01/01 +0000, Michael Stephenson wrote:
> > > b) static ThreadLocal, each Thread gets one instantiation.
> >
> > But I think some people are still using java 1.1.x and they don't have
> > ThreadLocal.
>
>Then they can stick with using one instantiation per object, this is
>really pulling our performance down, do some tests.

Yes, and as they are different classes (only built as required) this isn't
a problem.

> > > c) An Object Pool (possibly using SoftReferences to stop memory bloat),
> > > slightly more difficult to code, a lot less instantiations, much
> > > better performance.
> >
> > But there are so many different ones used and you would have to make a
> > pool for each one.
>
>SimpleDateFormat has a HUGE instantiation penalty, bigger than any other
>object in the jdk I can think of.
>
> > > If people agree that either 'b' or 'c' is a better solution, I'll go
> ahead
> > > and implement it.
> >
> > I don't agree. Part of java performance is memory usage. Introducing
> > memory pools means keeping objects around forever even if they are used
> > once.
>
>This is why I would use SoftReferences, this means when memory use is too
>high the virtual machine will just garbage collect them.
>
>Again, this is a 1.2 or greater solution.
>
> > In tests I've done to see if using static variables are usful
> > with string parsing I've found that gain is minimal.
>
>Strings have a low cost of instantiation, on my machine they take 0.0028
>compared to 0.58ms (Sun JDK1.2.2 linux, P2 733).
>
>This *IS* a big cost. Using SoftReferences in an object pool my initial
>tests are going in the same order of magnitude as the String
>instantiations (the main cost is the synchronisation).
>
> > Any call to
> > postgress will be disk and network bound and trying to introduce a pool
> > will only complicate things.
>
>There are already other Object pools for other things.

Ok, have you got any quick examples of this? I would like to nail the
Timestamp problems once and for all, so now's the time to sort this out.

Peter

In response to

Browse pgsql-interfaces by date

  From Date Subject
Next Message Peter Mount 2001-01-30 23:28:14 Re: Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems
Previous Message Peter Mount 2001-01-30 22:24:16 Re: [JDBC] Re: Postgresql and JDBC

Browse pgsql-jdbc by date

  From Date Subject
Next Message Peter Mount 2001-01-30 23:28:14 Re: Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems
Previous Message Peter Mount 2001-01-30 22:24:16 Re: [JDBC] Re: Postgresql and JDBC

Browse pgsql-patches by date

  From Date Subject
Next Message Peter Mount 2001-01-30 23:28:14 Re: Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems
Previous Message Joseph Shraibman 2001-01-30 22:23:18 Re: Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems