Re: Optimising Variable to reduce instantiation overhead

I haven't followed the precise details of the debate, but it seems to me=20
that Alex is correct.  That is, optimize for the non-exception case by=20
not constructing the display name for the variable, but synchronize=20
access to the method that does the lazy instantiation of the display=20
name.  Without synchronization it is possible that two threads (two=20
requests for the same template) could try to create the display name at=20
the same time with unpredictable results.  In most cases, with most=20
microprocessors, it wouldn't matter, as the processors provide stronger=20
memory barriers than are required by the Java specs.  But why take the=20
chance, especially when the cost is minuscule?

An alternative, if you *really* can't stand synchronization, would be to=20
get rid of the member variable altogether and just have the display name=20
computed every time it is requested.  I don't see any performance=20
benefit to this, but it would keep the state from being modified.

I also agree that it is a mistake to optimize exceptional cases without=20
any empirical evidence of a performance issue.  This is a classic case=20
of what Bruce Eckel ("Thinking in Java") calls "premature optimization".

Keats

Alex Twisleton-Wykeham-Fiennes wrote:

>On Fri 17 March 2006 11:31, Endre St=C3=B8lsvik wrote:
> =20
>
>>On Mon, 13 Mar 2006, Alex Twisleton-Wykeham-Fiennes wrote:
>>| On Mon 13 March 2006 12:34, Endre St=C3=B8lsvik wrote:
>>| > On Sun, 12 Mar 2006, Alex Twisleton-Wykeham-Fiennes wrote:
>>| > | All,
>>| > |
>>| > | more performance tweaks, this one to the org.webmacro.engine.Vari=
able
>>| > | class.
>>| >
>>| > Excellent performance tuneup you're into, Alex!
>>| >
>>| > | - made the getVariableName() method check to see if _vname has be=
en
>>| > | initialised, and if not then build the name before returning it.=20
>>| > | This is now synchronized as it changes the state of the object.
>>| >
>>| > So?
>>|
>>| If you don't synchronize then you could potentially have two threads
>>| modifying the state of the Object simultaneously.
>>
>>Not unless your code allows multithreaded acccess to a _shared instance=
_.
>>And you shouldn't, unless they absolutely have to exchange information
>>through this object.
>>   =20
>>
>
>But it *is* shared as Keats said.
>
> =20
>
>>|  In this situation it is not the end of the world, because the
>>| generation of the result is a) not that expensive, and b) not depende=
nt
>>| on other mutable properties, but I find it best to apply thread-safe
>>| approaches to everything that changes state and then remove them if
>>| profiling shows it to be a problem.  Much better to start safe and th=
en
>>| remove redundant safety when required than to start unsafe and try an=
d
>>| make things safe when a weird multi-threading bug occurs...
>>
>>I don't agree: putting synchronized on every bleedin method "just becau=
se"
>>is not a good strategy. If it can't be accessed by multiple threads, th=
en
>>multi-threading tactics aren't great. Beside hitting performance, they
>>may potentially give you new exciting problems with deadlocks.
>>   =20
>>
>
>It is not "just because", it is "because it reads the state of a mutable=
=20
>instance variable and then changes the state of the mutable instance var=
iable=20
>based on the read value".
>
>I would be very interested if you can show me a) some performance metric=
s that=20
>show that my lazy synchronized initialisation is hitting performance, an=
d b)=20
>how my synchronized code can generate a deadlock.  I will of course then=
=20
>change my implementation.
>
> =20
>
>>| > Is it shared across threads?
>>|
>>| I'd have to double check this one.  It's a bit of a twisty turny pass=
age
>>| of Macro inheritance and it isn't necessarily obvious...
>>
>>What has inheritance to do with this?
>>
>>If an object that implements Macro is _shared across threads_, then _th=
is_
>>class should do synchs on methods that change its internal state (and
>>generally not using the "method syncrhonziation" paradigm - read up on
>>"monitors"). But why should the general Macro-implementing objects of
>>WebMacro be shared across threads?!
>>   =20
>>
>
>Let's just assume that I don't know what I'm talking about for a moment.=
 =20
>Please explain at what point in the following I am on crack:-
>
>- Macro is an interface. =20
>- interfaces cannot specify synchronized in their declarations according=
 to=20
>the java language definition. =20
>- Variable implements Macro.
>- Variable has a method that checks for an internal variable to see if i=
t is=20
>null and sets it if it is null.
>- I would like this initialisation to only occur once so I want to synch=
ronize=20
>on something to achieve this.
>- I can't synchronize on the variable because it is null (initially)
>- I'm therefore left with the choice of synchronizing on the Object itse=
lf or=20
>creating a second Object inside the Variable to synchronize on.
>
>Am I missing something?
>
> =20
>
>>| ps synchronizing is really not the overhead that it used to be in old=
er
>>| JVMs and it *really* makes your life easier to not have any
>>| multi-threading bugs...
>>
>>Contended synchs are hell in any case.
>>
>>A synch, contended or not, have to flush all dirty cache to memory whet=
her
>>or not it is necessary. This is bad, and one should _not_ use synchs
>>unless it is multithreaded accessed.=20
>>   =20
>>
>
>But it *is* multithreaded accessed.  And even if it wasn't, you are not =
sure=20
>that it isn't or that it won't be in the future, so you write your code =
safe=20
>and then optimise it when / if performance becomes an issue.
>
>Alex
>
> =20
>




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
that extends applications into web and mobile media. Attend the live webc=
ast
and join the prime developer group breaking into this new coding territor=
y!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D=
121642