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