Обсуждение: synchronized code
I'm quite worried with the amount of synch'd code in our jdbc driver code, we all know this is a very costly operation in Java. As far as I could see from the sources, the sole objective of these calls are to avoid two processes accessing the same shared StringBuffer we use. The strangest thing, IMHO, is that every time we use this buffer, we are calling setLength(0) or, in plain english, resetting this buffer. Is just me the paranoid or this isn't helping performance at all? As I understand java, object creating is a very cheap operation these days (in the old days it was slow), but synch'ing is VERY costly... -- 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
Felipe Schnack <felipes@ritterdosreis.br> wrote: > I'm quite worried with the amount of synch'd code in our jdbc driver > code, we all know this is a very costly operation in Java. > As far as I could see from the sources, the sole objective of these > calls are to avoid two processes accessing the same shared StringBuffer > we use. The strangest thing, IMHO, is that every time we use this > buffer, we are calling setLength(0) or, in plain english, resetting this > buffer. Is just me the paranoid or this isn't helping performance at > all? As I understand java, object creating is a very cheap operation > these days (in the old days it was slow), but synch'ing is VERY > costly... Sun claims that with Java 1.4, synchronization isn't *that* expensive anymore. Anyway, object creation has improved, too. Which JVM are most people using? Probably more people still use 1.3, especially with J2EE. Just my $0.02. Regards, Michael
On 08 Jan 2003 16:43:11 -0200, Felipe Schnack wrote: > I'm quite worried with the amount of synch'd code in our jdbc driver >code, we all know this is a very costly operation in Java. > As far as I could see from the sources, the sole objective of these >calls are to avoid two processes accessing the same shared StringBuffer >we use. The strangest thing, IMHO, is that every time we use this >buffer, we are calling setLength(0) or, in plain english, resetting this >buffer. Is just me the paranoid or this isn't helping performance at >all? As I understand java, object creating is a very cheap operation >these days (in the old days it was slow), but synch'ing is VERY >costly... There's no reason to fear about synchronisation since Hotspot anymore. The lock, as only one process is building it, is definitely less work than the work the garbage collector has to do in a mark-sweep cycle to get rid of Stringbuffer over Stringbuffer (which would occur otherwise). That said, as the syncing is upon a Stringbuffer for EACH statement, and the statement class threaded use is discouraged anyway, we will probably never see code really running into this. As many many string operations are needed throughout the driver, the use of a sync'ed stringbuffer whenever bigger string operations are made is very wise and good style. Kudos here to the developer who made this... The only drawback is, for the developers, that they have to be a bit cautious with the use of it, not to produce deadlocks; but that's rather easy, as each and every statement has it's own and the statement class itself isn't that big. just my 0.02¬... sincerely, Patric Bechtel IPCON Informationssysteme
Yes, good java programmers use lots of StringBuffers :-) But about Statement in threaded use: this is discouraged by the spec or it isn't actually supported? On Wed, 2003-01-08 at 17:04, Patric Bechtel wrote: > On 08 Jan 2003 16:43:11 -0200, Felipe Schnack wrote: > > > I'm quite worried with the amount of synch'd code in our jdbc driver > >code, we all know this is a very costly operation in Java. > > As far as I could see from the sources, the sole objective of these > >calls are to avoid two processes accessing the same shared StringBuffer > >we use. The strangest thing, IMHO, is that every time we use this > >buffer, we are calling setLength(0) or, in plain english, resetting this > >buffer. Is just me the paranoid or this isn't helping performance at > >all? As I understand java, object creating is a very cheap operation > >these days (in the old days it was slow), but synch'ing is VERY > >costly... > > There's no reason to fear about synchronisation since Hotspot anymore. The > lock, as only one process is building it, is definitely less work > than the work the garbage collector has to do in a mark-sweep cycle to > get rid of Stringbuffer over Stringbuffer (which would occur otherwise). > That said, as the syncing is upon a Stringbuffer for EACH statement, and > the statement class threaded use is discouraged anyway, we will probably > never see code really running into this. > As many many string operations are needed throughout the driver, the use > of a sync'ed stringbuffer whenever bigger string operations are made > is very wise and good style. Kudos here to the developer who made this... > The only drawback is, for the developers, that they have to be a bit > cautious with the use of it, not to produce deadlocks; but that's > rather easy, as each and every statement has it's own and the statement > class itself isn't that big. > > just my 0.02¬... > > > > sincerely, > > Patric Bechtel > IPCON Informationssysteme > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- 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
Yes... but what got better with JVM 1.4 was synch'ing not object creation, so you're basically saying I'm correct? :-) In tomcat discussion lists, that I'm also in, is quite a common belief that object creating is cheaper... and they're also worried about 1.3 compatibility (just take a look at java.nio thread some weeks ago) Anyway, this is easily benchmarked. On Wed, 2003-01-08 at 16:53, Michael Paesold wrote: > Felipe Schnack <felipes@ritterdosreis.br> wrote: > > > I'm quite worried with the amount of synch'd code in our jdbc driver > > code, we all know this is a very costly operation in Java. > > As far as I could see from the sources, the sole objective of these > > calls are to avoid two processes accessing the same shared StringBuffer > > we use. The strangest thing, IMHO, is that every time we use this > > buffer, we are calling setLength(0) or, in plain english, resetting this > > buffer. Is just me the paranoid or this isn't helping performance at > > all? As I understand java, object creating is a very cheap operation > > these days (in the old days it was slow), but synch'ing is VERY > > costly... > > Sun claims that with Java 1.4, synchronization isn't *that* expensive > anymore. Anyway, object creation has improved, too. Which JVM are most > people using? Probably more people still use 1.3, especially with J2EE. Just > my $0.02. > > Regards, > Michael > > > ---------------------------(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
Felipe Schnack <felipes@ritterdosreis.br> wrote:
> Is... but what got better with JVM 1.4 was synch'ing not object
> creation, so you're basically saying I'm correct? :-)
I think it depends on the virtual machine, but I'm no expert.
I just had a look at the latest StringBuffer sources. What setLength(0)
does, is to wipe the whole buffer with null-bytes ('\0') in a loop! Although
I have no idea why it is done, it seems to be very inefficient. Especially
when you think of the fact, that this single StringBuffer will grow,
everytime a bigger string is put into it. It seams that sb.delete(0,
sb.length); is much more efficient. It just resets the internal length
counter?
Any comments?
Regards,
Michael Paesold
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?
On Wed, 2003-01-08 at 18:16, Michael Paesold wrote:
> Felipe Schnack <felipes@ritterdosreis.br> wrote:
>
> > Is... but what got better with JVM 1.4 was synch'ing not object
> > creation, so you're basically saying I'm correct? :-)
>
> I think it depends on the virtual machine, but I'm no expert.
>
> I just had a look at the latest StringBuffer sources. What setLength(0)
> does, is to wipe the whole buffer with null-bytes ('\0') in a loop! Although
> I have no idea why it is done, it seems to be very inefficient. Especially
> when you think of the fact, that this single StringBuffer will grow,
> everytime a bigger string is put into it. It seams that sb.delete(0,
> sb.length); is much more efficient. It just resets the internal length
> counter?
>
> Any comments?
>
> Regards,
> Michael Paesold
>
--
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
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
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
Oliver, What you need to be testing is syncronization vs. object allocation *and* garbage collection. How are you testing the overhead that the garbage collection adds since garbage collection in java by its nature is something that is async. Perhaps having a System.gc() call at the end of each test would be sufficient? thanks, --Barry 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 >
On Wed, Jan 08, 2003 at 01:56:19PM -0800, Barry Lind wrote: > Oliver, > > What you need to be testing is syncronization vs. object allocation > *and* garbage collection. How are you testing the overhead that the > garbage collection adds since garbage collection in java by its nature > is something that is async. > > Perhaps having a System.gc() call at the end of each test would be > sufficient? I'm timing total throughput across all threads vs. elapsed real time so GC should be included. -verbose:gc shows that minor GCs are, in fact, happening frequently (2-3 per second) -O
Felipe Schnack <felipes@ritterdosreis.br> 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, I am really sorry, just re-read the code. I only fills the rest of the StringBuffer with '\0' bytes, if the new length is _longer_ than the old. My mistake. So setLength(0) is not expensive. Btw. there is a src.zip in any j2sdk distribution that contains pretty much all the java source code. I would be very much interested in benchmarks with jdk 1.3, too. Michael
Felipe,
Actually in many cases the size of the EXECUTE may be much larger than
the PREPARE. It all depends on the number, type and size of your bind
variables. It is very easy to have bytea or text bind variables that
are many times larger than the original query. It all depends on what
you are doing.
--Barry
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?
>
> On Wed, 2003-01-08 at 18:16, Michael Paesold wrote:
>
>>Felipe Schnack <felipes@ritterdosreis.br> wrote:
>>
>>
>>> Is... but what got better with JVM 1.4 was synch'ing not object
>>>creation, so you're basically saying I'm correct? :-)
>>
>>I think it depends on the virtual machine, but I'm no expert.
>>
>>I just had a look at the latest StringBuffer sources. What setLength(0)
>>does, is to wipe the whole buffer with null-bytes ('\0') in a loop! Although
>>I have no idea why it is done, it seems to be very inefficient. Especially
>>when you think of the fact, that this single StringBuffer will grow,
>>everytime a bigger string is put into it. It seams that sb.delete(0,
>>sb.length); is much more efficient. It just resets the internal length
>>counter?
>>
>>Any comments?
>>
>>Regards,
>>Michael Paesold
>>
On Thu, Jan 09, 2003 at 10:40:33AM +1300, Oliver Jowett wrote: > Actual numbers to follow when I'm done. The detailed data (and source) is now at: http://www.randomly.org/misc/java-allocation-pooling-benchmark.txt Summary: With no lock contention: Client VM: allocation is about twice as fast as synchronizing. Server VM: allocation is about 5% slower than synchronizing. With lock contention, synchronizing is dramatically slower than allocation using either VM type; this effect is worse when multiple CPUs are used. There's very little difference between allocating a new buffer each time, or reusing an buffer via setLength(0), ignoring synchronization. In some cases (e.g. 2 cpus with spare capacity) allocating a new object is faster! There's another effect in here somewhere that's generating some noise. (compare "no synchronization" to "synchronized buffer" for one thread -- sometimes the synchronized version is faster, but they're doing the same operations other than synchronization so I'd expect it to be always slower). Reviewing the code, this may be due to a different cost in accessing locals vs. instance fields. If so this will also affect the synchronization vs. allocation case. ... but enough benchmarking for one day I think! -O
you're right, my mistake
On Wed, 2003-01-08 at 21:19, Barry Lind wrote:
> Felipe,
>
> Actually in many cases the size of the EXECUTE may be much larger than
> the PREPARE. It all depends on the number, type and size of your bind
> variables. It is very easy to have bytea or text bind variables that
> are many times larger than the original query. It all depends on what
> you are doing.
>
> --Barry
>
> 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?
> >
> > On Wed, 2003-01-08 at 18:16, Michael Paesold wrote:
> >
> >>Felipe Schnack <felipes@ritterdosreis.br> wrote:
> >>
> >>
> >>> Is... but what got better with JVM 1.4 was synch'ing not object
> >>>creation, so you're basically saying I'm correct? :-)
> >>
> >>I think it depends on the virtual machine, but I'm no expert.
> >>
> >>I just had a look at the latest StringBuffer sources. What setLength(0)
> >>does, is to wipe the whole buffer with null-bytes ('\0') in a loop! Although
> >>I have no idea why it is done, it seems to be very inefficient. Especially
> >>when you think of the fact, that this single StringBuffer will grow,
> >>everytime a bigger string is put into it. It seams that sb.delete(0,
> >>sb.length); is much more efficient. It just resets the internal length
> >>counter?
> >>
> >>Any comments?
> >>
> >>Regards,
> >>Michael Paesold
> >>
>
>
>
--
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
Well, I still have the same opinion about this issue... but would be really nice to have these same benchmarks run in JDK 1.4 and 1.3 in the same machine. I'll try to do it later, I'm downloading the sources. On Thu, 2003-01-09 at 08:39, Oliver Jowett wrote: > On Thu, Jan 09, 2003 at 10:40:33AM +1300, Oliver Jowett wrote: > > > Actual numbers to follow when I'm done. > > The detailed data (and source) is now at: > > http://www.randomly.org/misc/java-allocation-pooling-benchmark.txt > > Summary: > > With no lock contention: > Client VM: allocation is about twice as fast as synchronizing. > Server VM: allocation is about 5% slower than synchronizing. > > With lock contention, synchronizing is dramatically slower than allocation > using either VM type; this effect is worse when multiple CPUs are used. > > There's very little difference between allocating a new buffer each time, > or reusing an buffer via setLength(0), ignoring synchronization. In some > cases (e.g. 2 cpus with spare capacity) allocating a new object is faster! > > There's another effect in here somewhere that's generating some noise. > (compare "no synchronization" to "synchronized buffer" for one thread -- > sometimes the synchronized version is faster, but they're doing the same > operations other than synchronization so I'd expect it to be always > slower). Reviewing the code, this may be due to a different cost in > accessing locals vs. instance fields. If so this will also affect > the synchronization vs. allocation case. > > ... but enough benchmarking for one day I think! > > -O > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- 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
Calling System.gc() don't necessarly executes garbage collecting, it just gives a "hint" to the garbage collector... anyway, I don't see why this would add so much overhead (creating lots of objects) On Wed, 2003-01-08 at 19:59, Oliver Jowett wrote: > On Wed, Jan 08, 2003 at 01:56:19PM -0800, Barry Lind wrote: > > Oliver, > > > > What you need to be testing is syncronization vs. object allocation > > *and* garbage collection. How are you testing the overhead that the > > garbage collection adds since garbage collection in java by its nature > > is something that is async. > > > > Perhaps having a System.gc() call at the end of each test would be > > sufficient? > > I'm timing total throughput across all threads vs. elapsed real time so GC > should be included. -verbose:gc shows that minor GCs are, in fact, happening > frequently (2-3 per second) > > -O > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- 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
I think you should, you know... J2EE, not really old applications On Thu, 2003-01-09 at 09:06, Oliver Jowett wrote: > On Thu, Jan 09, 2003 at 08:57:19AM -0200, Felipe Schnack wrote: > > Well, I still have the same opinion about this issue... but would be > > really nice to have these same benchmarks run in JDK 1.4 and 1.3 in the > > same machine. I'll try to do it later, I'm downloading the sources. > > Ok, I'll see if I can fit it in tomorrow (but we're not targetting 1.3 > ourselves, so it's lower priority) > > -O -- 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
Oliver, Thanks for your work on this. However to really get a good idea I think we need to see the results for other platforms and other jvms. I would like it if we had data from: sun 1.4 jvm on Solaris (done) sun 1.3 jvm on Solaris sun 1.4 jvm on linux sun 1.3 jvm on linux ibm 1.3 jvm on linux gcj jvm on linux sun 1.4 jvm on windows sun 1.3 jvm on windows ibm 1.3 jvm on windows (Is there a 1.4 IBM out yet, it has been a while since I looked at the IBM site). Does anyone have the time to run this on these other platforms? thanks, --Barry Oliver Jowett wrote: > On Thu, Jan 09, 2003 at 10:40:33AM +1300, Oliver Jowett wrote: > > >>Actual numbers to follow when I'm done. > > > The detailed data (and source) is now at: > > http://www.randomly.org/misc/java-allocation-pooling-benchmark.txt > > Summary: > > With no lock contention: > Client VM: allocation is about twice as fast as synchronizing. > Server VM: allocation is about 5% slower than synchronizing. > > With lock contention, synchronizing is dramatically slower than allocation > using either VM type; this effect is worse when multiple CPUs are used. > > There's very little difference between allocating a new buffer each time, > or reusing an buffer via setLength(0), ignoring synchronization. In some > cases (e.g. 2 cpus with spare capacity) allocating a new object is faster! > > There's another effect in here somewhere that's generating some noise. > (compare "no synchronization" to "synchronized buffer" for one thread -- > sometimes the synchronized version is faster, but they're doing the same > operations other than synchronization so I'd expect it to be always > slower). Reviewing the code, this may be due to a different cost in > accessing locals vs. instance fields. If so this will also affect > the synchronization vs. allocation case. > > ... but enough benchmarking for one day I think! > > -O > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
Yes, that's what I meant... but which are the reasons? Compatibility must be a preocupation, JDK 1.3 is widely used it, like it or not :-) On Thu, 2003-01-09 at 18:32, Oliver Jowett wrote: > On Thu, Jan 09, 2003 at 09:18:18AM -0200, Felipe Schnack wrote: > > I think you should, you know... J2EE, not really old applications > > I don't understand what you mean here.. > > We're targetting 1.4 instead of 1.3 for reasons that have nothing to do with > the availability of J2EE servers, if that's what you meant. > > > On Thu, 2003-01-09 at 09:06, Oliver Jowett wrote: > > > On Thu, Jan 09, 2003 at 08:57:19AM -0200, Felipe Schnack wrote: > > > > Well, I still have the same opinion about this issue... but would be > > > > really nice to have these same benchmarks run in JDK 1.4 and 1.3 in the > > > > same machine. I'll try to do it later, I'm downloading the sources. > > > > > > Ok, I'll see if I can fit it in tomorrow (but we're not targetting 1.3 > > > ourselves, so it's lower priority) > > -O -- 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