in your case (Magma) you can do even better: at the beginning of transaction make a deep copy of object graph. Upon finishing transaction, you walk the modified graph and compare objects if they are changed or not. This could be somewhat memory-hungry (but do we care?), but you don't have to use anything like write barrier or overriding compiled methods.
And with having a per-object properties, it just another piece of cake:
Object>>maIsChanged ^ (self propertyAt: #originalCopy) = self
and for nested transactions, you can make it even more hungry
Object>>maIsChangedIn: transaction ^ (self propertyAt: transaction) = self
:) but nested (and not even) transactions implying anyways that you hold the original somewhere, to be able to roll back the changes.
So in case of rollback, all you need to do is to send #restore to the root object:
Object>>restore self befomeForward: (self propertyAt:#originalCopy). self allIvarsDo: [:each | each restore]
Now, add there a VM primitive which can quickly mark a graph starting from your roots, and stockpile marked objects into some array, and you will have a super fast thingy :)
On 12 June 2012 00:00, Chris Muller ma.chris.m@gmail.com wrote:
(discussion branch moved to Magma list).
Well, I doubt it's faster than just using Avi's regular WriteBarrier. Understand the overrides are only compiled once per class, not once per object. In the real world compilation is not a significant factor on performance.
The overridden methods follow the pattern:
someMethod | t1 t2 newT1 newT2 returnValue | t1 := self instVarAt: 1. t2 := self instVarAt: 2. returnValue := super someMethod. newT1==t1 ifFalse: [ self modified. ^ returnValue ]. newT2==t2 ifFalse: [ self modified. ^ returnValue ]. ^ returnValue
which is probably even faster than unwinding stack all the way to the Immutable handler every time an attribute is set. Not sure, but the above is fast enough to accomplish the overall goal and substantially improve app performance.
Ok, what if we call it a "fast write-barrier provided by the VM". Would that change your view? Igor?
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma