Alexandru Popescu ☀ wrote:

The issue is not the volatility of the variable it's the volatility of the behaviour of the value of the variable. Declaring a variable volatile is irrelevant.

However the behaviour of the object may be changed as a result of performing an operation on the object (because the MetaClass can change its behaviour as a result of an operation being performed via the MetaClass). That is to say that you don't just have to worry about another thread monkey patching the behaviour of Integer you have to worry about your own thread monkey patching the behaviour of Integer. So every time you make a method call you have to check to see if the behaviour is changed. However as everything goes via the MetaClass you are making a method call per operation so you *can't* assume that the behaviour of Integer is unchanged for the duration of an expression.

We're trying to run before we can walk.

There's a huge performance gain available by doing straightforward optimisation of the execution paths through the run time system. It's not productive to expend effort on questionable "optimisation" special cases when the general case can be vastly improved. You need to solve the general problem satisfactorily before addressing the special cases.

John Wilson

-- View this message in context:
http://www.nabble.com/as-usual-on-performance---operations-on-primitives-tp15713441p15734481.html Sent from the groovy - dev mailing list archive at Nabble.com.

--------------------------------------------------------------------- To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email