Re: Optimising Variable to reduce instantiation overhead

On Mon, 13 Mar 2006, Alex Twisleton-Wykeham-Fiennes wrote:

| On Mon 13 March 2006 12:34, Endre Stølsvik wrote:
| > On Sun, 12 Mar 2006, Alex Twisleton-Wykeham-Fiennes wrote:
| > | All,
| > |
| > | more performance tweaks, this one to the org.webmacro.engine.Variable
| > | class.
| >
| > Excellent performance tuneup you're into, Alex!
| >
| > | - made the getVariableName() method check to see if _vname has been
| > | initialised, and if not then build the name before returning it.  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.

|  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 dependent 
| 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 then 
| remove redundant safety when required than to start unsafe and try and 
| make things safe when a weird multi-threading bug occurs...

I don't agree: putting synchronized on every bleedin method "just because" 
is not a good strategy. If it can't be accessed by multiple threads, then 
multi-threading tactics aren't great. Beside hitting performance, they 
may potentially give you new exciting problems with deadlocks.

| 
| > Is it shared across threads?
| 
| I'd have to double check this one.  It's a bit of a twisty turny passage 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 _this_ 
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?!

| 
| Alex
| 
| ps synchronizing is really not the overhead that it used to be in older 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 whether 
or not it is necessary. This is bad, and one should _not_ use synchs 
unless it is multithreaded accessed. This is the same reason why the 
Collections framework was made unsynched (as opposed to the idiotic 
synched Vectors and Hashtable), and that _finally_ they've made a new 
StringBuffer (StringBuilder) that is unsynched (can you _believe_ that 
StringBuffer is synched? I was shocked to find out..).

Endre.