Hi!
I was starting up our Gjallar system today on an existing db and after having done class changes (but I am unsure of what they were) and it took *forever*. Eventually I used ProcessBrowser to sample a message profile on it and it is attached. It seems to spend 95% digging out class comments?
Oh well, I guess it could be interesting.
Today I have also witnessed some odd things happening with objects in a plain Dictionary. I am not sure it has to do with Magma - but it smells. An instvar that I definitely don't assign to other than in initialize - it suddenly held onto an OrderedCollectio() instead of a Q2Person. When digging around I also ended up with this Dictionary having integers as both keys and values - it should be an email String as key and a Q2Person as value.
Hard to replicate of course, just wanted to mention it.
regards, Göran
Hi Göran, something is wrong, I hope you did not do any commits under those strange conditions. You need to close down and instantiate a new session, hopefully that will clear it up.
If not then we should probably suspect those class changes and watch it materialize an instance of that class. I assume this is a class with only named instVars; Magma should map them by name.
I have no idea why it is spending so much time building the classDefinitions map but I think you should explore your class defintions and see if it has gone "hog wild" adding a more than it should; i.e., is the classDefinitionsById dictionary larger than, say, 1000 (classes) or is any one entry have more than, say, just a few versions (like 5 or so, depending on how many class changes you've made over time).
(classDefinintionsById collect: [ : each | each size ]) asBag sortedCounts
Materialization occurs in two steps; first is to instantiate the object with all of the variables pointing to the integer oids; the Dictionary you saw with all integers is an example of that; an object that has only undergone the first stage of materialization but not the second. Once all objects have been populated with the oids the second step is to then convert those oids to the actual object instances.
Put a halt in MaFixedObjectBuffer>>createObjectUsing: if the 'class' temporary variable is of the one that you made changes or otherwise showing problems. This is first stage of materialization. Hopefully the code will make sense, but if any questions please free to ask.
Here you can see which definitions (sourceDefinition and inImageDefinition) it will use to map the old persistent instance to the new instVar mappings. The oids will be put in the appropriate place accordingly. The second step, MaFixedObjectBuffer>>#establishReferencesFrom:using: will convert those oids to the actual objects.
Good luck, please let me know if I can help, Chris
--- goran@krampe.se wrote:
Hi!
I was starting up our Gjallar system today on an existing db and after having done class changes (but I am unsure of what they were) and it took *forever*. Eventually I used ProcessBrowser to sample a message profile on it and it is attached. It seems to spend 95% digging out class comments?
Oh well, I guess it could be interesting.
Today I have also witnessed some odd things happening with objects in a plain Dictionary. I am not sure it has to do with Magma - but it smells. An instvar that I definitely don't assign to other than in initialize
it suddenly held onto an OrderedCollectio() instead of a Q2Person. When digging around I also ended up with this Dictionary having integers as both keys and values - it should be an email String as key and a Q2Person as value.
Hard to replicate of course, just wanted to mention it.
regards, Göran> _______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
magma@lists.squeakfoundation.org