Have an idea to improve LinkedIn? Please submit your suggestion below.
Have you seen application performance dip when implementing immutable objects? Also, what are some examples where mutable objects are the better choice?
Clarification added 5 months ago:
I'd also like to hear about your experiences with this practice. Did it reduce the number of defects? Simplify maintenance? Make existing code more robust for adding enhancements, etc?
Clarification added 4 months ago:
Thanks for the answers so far. I'm building a small application to try out immutability and after getting my domain classes set up, I started thinking about the web layer and forms. If domain objects are immutable, do I need a set of mutable DTOs back my forms with? I assume all validations etc are done on these DTOs and once they have all the required data, I just copy the values to their respective domain objects?
Answers (2)
The answer is from the java perspective, thought it might be relevant in other languages.
Usually immutable are a better choice then mutable. Creating an object with modern JVMs is very fast and the garbage collector is checking for the immutability of an object and is handling them faster if they are (since it knows they will not change). In addition, modern JVMs are using "escape analysis" which enables them to allocate the objects on the stack and dispose of them with one stroke (no GC involved).
Programatic wise, immutable are inherently thread safe and thus less prone to cause concurrency bugs, simplify maintenance etc.
Reasons not to use immutable is excessive garbage causing the GC to spend too much CPU time. If the objects are long lived then some GCs will handle them less efficiently (so better to reuse). And of course, if the object is very expensive to create (initializing heavy resources or bootstrap code) then you might want to minimize their creation.
The best practice is to test the two approaches in your production JVM with few GCs and compare results.
Links:
Disclaimer: I'm a Java developer and a real purist and obviously it affects my answer.
Just as Eishay Smith have said, Object creation in modern JVMs (1.4+) is extremely fast. As far as my experience go, using immutable objects in a multi-threaded environment actually increases your performance by saving synchronization time and (1.5+) allowing most locks to remain on the fast track (uncontested) instead of degrading to the slow track (contested). On JVM 1.7 (scheduled to come sometime next year) the new. non-generational GC would even work better with sets of short lived objects.
Development and maintenance wise, immutable objects are a bliss, compared to mutable objects. While advantages are numerous, I'd like to point the 3 I think matter most:
1. You can identify exactly where your object (data) changes and define explicit, cross-concern rules to how that can happen (thread safety, logging, permissions).
2. You can never have object in a half-state. Even the best programmers forget some things, and even the best designs are changed later on. Relying on immutable objects means you have to supply all parameters in the creation of the object. Changing the definition later on would force you to adapt existing code.
3. [Somewhat UI oriented]: You can create object history and keep versions with ease. This is extremely important for proper caching, but also ease the creation of undo mechanisms and operation history.
However, there are disadvantages to using immutable objects:
1. GC IS going to take longer. This does not always correlate to a degradation on performance, but it might.
2. Code IS going to be more elaborate and there will be less "shortcuts". While this is great for later on, it might hinder first development effort.
3. At some point you have to break the immutability of your data structures, or sacrifice performance for copying mostly data from one memory location to another. Think of a datum A held by an object B. Say that the datum changes to A' - would you change B or recreate it? At some point along you would have to compromise in order to not recreate your entire data structure from scratch each time a tiny change takes effect.
4. As Mr Smith noted, not all objects can be immutable. Resources and OS-dependent objects must be pooled or recycled.
And of course, if performance is key, only benchmarking would reveal the real impact.