> > Bruce Eckel on his book "Thinking in Java" states that a simple
> > method call (no parameters) takes 5.9 units of time while a
> > synchronized method call takes 570. OTOH, object creation takes
> > 980 which makes it an even worse alternative.
>
> Normally I would say that numbers such as these should be taken with a
> grain of salt. For example, object creation has side effects that will
> affect the times of subsequent garbage collections; and synchronization can
> affect the performance of other threads.
>
> However, if a synchronized method call takes on the order of the time of an
> object creation (which makes sense as object creation is likely
> synchronized itself), then I would be inclined to say that this overhead is
> quite small compared to the overall processing of an HTTP request as such
> involves the creation of a quite large number of objects. So, if a
> relatively small number of these operations were done per request, then the
> right course of action would be to replace the code with the safest,
> simplest, and most maintainable alternative, namely a simple
> synchronization block without the outer if statement.
Well, I would disagree with this. First, processing an HTTP requests
doesn't require "creation of a quite large number of objects" - 3.x is
down to almost 6 objects, and that's only because I didn't had the time to
finish ( and 6 is not a big number - it used to be >50 ). IMHO it's a
matter of weeks to get this down to 1 ( the Socket object - not a problem
in ajp13, only in standalone mode ).
You are right - object creation and GC both require synchronization.
( BTW, since we are talking about sync - there are quite a few tricks in
ThreadPool and the server design to minimize the number of syncs per
request )
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
