Re: Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems
От | Peter Mount |
---|---|
Тема | Re: Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems |
Дата | |
Msg-id | 5.0.2.1.0.20010130232320.009f7570@mail.retep.org.uk обсуждение исходный текст |
Ответ на | Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems (Joseph Shraibman <jks@selectacast.net>) |
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: