Re: Optimising Variable to reduce instantiation overhead
Endre Stølsvik <[email protected]> Mon, 20 Mar 2006 14:59:16 +0100 (CET)
| Newsgroups | gmane.comp.java.webmacro.user |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 17 Mar 2006, Keats Kirsch wrote:
| I haven't followed the precise details of the debate, but it seems to me that
| Alex is correct. That is, optimize for the non-exception case by not
| constructing the display name for the variable, but synchronize access to the
| method that does the lazy instantiation of the display name. Without
| synchronization it is possible that two threads (two requests for the same
| template) could try to create the display name at the same time with
| unpredictable results. In most cases, with most microprocessors, it wouldn't
| matter, as the processors provide stronger memory barriers than are required
| by the Java specs. But why take the chance, especially when the cost is
| minuscule?
I do get that _Templates_ are shared. But are all Macro-implementing
objects in WebMacro shared?
I am just asking here, really.
(.. maybe this then should be worked over?! The synched Map/Set/Whatever
lookup must be hitting hard?!).
|
| An alternative, if you *really* can't stand synchronization, would be to get
| rid of the member variable altogether and just have the display name computed
| every time it is requested.
That is a very good idea, and way better if this is a method that wont be
called in the standard case.
| I don't see any performance benefit to this, but
| it would keep the state from being modified.
Immutables are the very best paradigm when it comes to multithreading, if
possible. IMO.
|
| I also agree that it is a mistake to optimize exceptional cases without any
| empirical evidence of a performance issue. This is a classic case of what
| Bruce Eckel ("Thinking in Java") calls "premature optimization".
Well, the same goes for syncronization, doesn't it?
Don't synch if you don't need to, kinda. And if you need to, then do you
really?? (.. and here you don't, as you perfectly point out).
Regards,
Endre.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642