While I can't be certain, based on the decription, the time appears to be spent determining what objects are still referenced. One source of time not charged by the profiler to particular lines of code is the time spent destroying a function workspace. This can take a long time if the workspace contains handles to objects and it is not obvious to the system that such handle is either the last references to an object or definitely not the last reference. Earlier versions of MATLAB use a combination of reference counting and a form of cycle detection to ensure that cycles of objects aren?t orphaned. The cycle detection can be very expensive but various optimizations allow cycle detection information to be cached and reused when later references are removed. I suspect that the act of creating the property change event for the SetObservable Data property causes one of these caches to be invalidated and forces a traversal of all the connected objects and data. Even though there are no listeners, a temporary reference to the Source object is created and then destroyed and this action can invalidate cached cycle-related information. MATLAB versions since R2011b have a new lifecycle management system that is designed to provide faster and more uniform performance.
"Joseph Burgel" wrote in message <firstname.lastname@example.org>... > I added up all the time each line took to execute in my method and it added up to about .4 sec so that left 31.6 sec un-accounted for and no way to further deduce what was taking so long. > > I then began a 'divide and concur' approach to finding the issue and determined it was being caused by clearing a Matlab OO property defined as follows: > > properties (Access = 'public', Dependent = true, SetObservable) > Data %The Data for the parameter. see Dimension. For type > end