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

> > 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.

> > 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.

Michael Stephenson      mstephenson@openworld.co.uk
Developer   -    Web Applications    -   Open World
Tel: +44 1225 444 950         Fax: +44 1225 336 738