Re: synchronized code
От | Felipe Schnack |
---|---|
Тема | Re: synchronized code |
Дата | |
Msg-id | 1042062469.11829.176.camel@desenv1.ritterdosreis.br обсуждение исходный текст |
Ответ на | Re: synchronized code (Oliver Jowett <oliver@opencloud.com>) |
Список | pgsql-jdbc |
Interesting information, I just can't understand why in multiprocessor environments synch'ing is faster. Anyway, I guess would be nice to benchmark against JDK 1.3... mainly because no arguments using JDK 1.4 will not convince most developers :-) On Wed, 2003-01-08 at 19:40, Oliver Jowett wrote: > On Wed, Jan 08, 2003 at 07:11:46PM -0200, Felipe Schnack wrote: > > yuck! I think this implementation is kinda gross (can you send me this > > source? Just curious). Just imagine using preparedstatements, you will > > allocate a big internal buffer (to store the "PREPARE", etc command) and > > then just execute much smaller "EXECUTE" calls. > > Well, what we have to decide is what is better: > > - Create and destroy StringBuffer objects. This adds object creation > > overhead (as far as I know this isn't a problem) and gc overhead (I have > > no idea if it's costly) > > - Continue the way it is, or: use a unique StringBuffer, that is > > synchronized in every use (maybe it's better now, but historically a > > costly operation, AFAIK) and have its contents reset every time (IMHO a > > bad programming pratice - easily someone will forget to do it - and as > > pointed out by Michael, not very effective). > > My opinion is quite clear, isn't it? > > I'm in the process of benchmarking this at the moment (we have similar > decisions to make in our own project). At this point, using a 1.4.0 VM on > Solaris 8, it looks like object allocation is faster than synchronization > with: > > - 1 cpu + server VM + lock contention > - >1 cpu + server VM > - client VM > > Synchronization is slightly (5%) faster for 1 cpu + server VM + no lock > contention. > > Actual numbers to follow when I'm done. > > -O > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Felipe Schnack Analista de Sistemas felipes@ritterdosreis.br Cel.: (51)91287530 Linux Counter #281893 Centro Universitário Ritter dos Reis http://www.ritterdosreis.br ritter@ritterdosreis.br Fone/Fax.: (51)32303341
В списке pgsql-jdbc по дате отправления: