Magma on 3.7 report

[Chris Muller]

Hey Bert, what OS are you using? (my gut tells me Mac)..  You may be blazing new trails here, I have not heard any experience reports from Mac users.  Anyone?
 
 > However, there is one central report touching almost the whole model,
 > which I had to interrupt after a quarter of an hour. It was taking
 > way too long., I guess Magma was bringing in objects and throwing
 > them out over and over again. I might easily be wrong though.
 
 This should not happen, the ReadStrategy is a default minimumDepth of 1.  It awards a +1 for Collections, so unless your model has any Collections of Collections it should stop reading.  If this is still a problem can you share a bit more about this?
 
 If it is, in fact, a ReadStrategy issue, interruptting it after a long time, and then asking your session for the #cachedObjectCountByClass, may help provide a clue to the issue.
 
 > What strategy is in place to stub out objects? Actually I don't need
 > any weak caching, I just need the commit. The whole model fits easily
 > into main memory. Can I disable that? If not, how could I find out
 > what's going on?
 
 WriterBarrier can make a significant difference, but does increase complexity..
 
 Otherwise, having the entire model in memory may slow down commits because a "comparison" is performed on every in-memory object to its original buffer for each commit.  You can use MagmaSession>>#stubOut: to chop off large branches of the model (leaving a proxy stub) to keep this operation lean.
 
 Regards,
   Chris