How about this change, if it rebuilds the whole list, we can savely remove
the selection, or not?
MorphTreeMorph>>
addSubmorphsFromNodeList: aNodeList previouslyExpanded: expandedNodeList
| morphList |
morphList := OrderedCollection new.
self
addMorphsTo: morphList
from: aNodeList
withExpandedItems: expandedNodeList
atLevel: 0.
self insertNewMorphs: morphList.
self listManager emptySelection. "<--- added"
self listManager updateSelectionFromModel.
self roots do: [:r | r updateChildrenRecursively].
self updateColumnMorphs
2014-06-30 15:35 GMT+02:00 Goubier Thierry <[email protected]>:
> Ok, I have the test case showing the problem.
>
> | c w t |
> c := ClassTreeExample new.
> w := c openOn: Collection.
> t := c dependents last.
> t expandAll.
> t selectAll.
> c updateList.
> t listManager selectedMorphList do: [ :each | self assert: ( t
> allNodeMorphs includes: each ) ]
>
> Fail on the final assert. Switching to single selection hold the same
> error.
>
> Interestingly, reselecting cleans the selectedMorphList.
>
> | c w t |
> c := ClassTreeExample new.
> w := c openOn: Collection.
> t := c dependents last.
> t expandAll.
> t selectAll.
> c updateList.
> t setSelectedMorph: t allNodeMorphs first.
> t listManager selectedMorphList do: [ :each | self assert: ( t
> allNodeMorphs includes: each ) ]
>
> This one has no error.
>
> Changing the way Nautilus maintain the selection would work. Forcing
> selectedMorphList to be cleaned up on addition / removal in the list would
> be nice too (but possible update code can delete the node morphs by itself).
>
> Thierry
>
>
> Le 30/06/2014 10:15, Johan Brichau a écrit :
>
>> Hi Nicolai,
>>
>>
>> Do you have a method selected in the browser?
>> As the memory leak happens via the selectedMorphs instvar, it requires a
>> package to be selected (and maybe even a method).
>>
>> Before and after the load. I do this and notice the increase.
>>
>> Smalltalk garbageCollect.
>> MorphTreeNodeMorph allInstances size.
>>
>> It really only becomes problematic (i.e. out-of-mem) when you load large
>> projects. Maybe MOOSE will qualify?
>>
>> Yes, I was astonished as well when I noticed that every update was
>> rebuilding the entire set of Morphs. It's the easiest solution of course
>> but it does impose a lot of overhead.
>> First, I will see how to solve that leaking problem. Then I will take a
>> look at the update itself.
>>
>> I can only spend some of my free time on this, so I will continue tonight.
>>
>> best,
>> Johan
>>
>> On 30 Jun 2014, at 09:09, Nicolai Hess <[email protected]> wrote:
>>
>> 2014-06-29 22:31 GMT+02:00 Johan Brichau <[email protected]>:
>>>
>>> On 27 Jun 2014, at 14:00, Goubier Thierry <[email protected]>
>>> wrote:
>>>
>>> It seems to depend on the Nautilus window state. If you've just opened
>>>> it, then nothing seems to be amiss. If you start to select things in it,
>>>> you start to see time spent in updateClassView, but why?
>>>>
>>>
>>> I just found that the instances are being kept by the
>>> MorphTreeListManager#selectedMorphs instvar. So, that observation is
>>> correct: you need to have a package selected.
>>>
>>> What seems to happen is that on every package load, the Nautilus package
>>> tree is updated (which means a PackageTreePackageNodeModel is created for
>>> each package in the image via #asNautilusNodeWithModel:).
>>> This update does not clear the selectedMorphs list and just this single
>>> reference seem to keep the entire package tree model and its Morphs in
>>> memory.
>>>
>>> There were 496 morphs in the selectedMorphs list and when I cleaned
>>> that, all trailing Morphs and PackageNodeModelNodes (and all the other
>>> garbage) could be gc'ed.
>>>
>>> On to investigating the growth of the selectedMorphs variable...
>>>
>>> Johan
>>>
>>>
>>> Yes, we had quite some bugs with this package tree update in the past.
>>> What I don't understand is, why
>>> is the whole tree removed and rebuild, maybe this is a common strategy
>>> in Morphic, update a list ore tree
>>> will always rebuild the whole morph structure? But it happens even if
>>> the structure is the same and
>>> just this little package/dirty package icon is updated.
>>>
>>> Another issue is this "selected package/package selection". The tree
>>> (and for example the
>>> category list and/or method list" as well), stores the selection on
>>> multiple ways, in the model (PackageTreeNautilus), the
>>> UI (PackageTreeNautilusUi) and the treelist morph. Once as a
>>> SelectedTreeNode, a Package from Nautilus Model and
>>> once as a PackgeTreeSelection/PackageTreeTagSelection.
>>> I find it pretty confusing.
>>>
>>>
>>> BTW, I still can not reproduce this memory leak behavior. I tried this:
>>>
>>> [ Gofer new smalltalkhubUser: 'ObjectProfile'
>>> project: 'Roassal2';
>>> package: 'ConfigurationOfRoassal2';
>>> load.
>>> (Smalltalk at: #ConfigurationOfRoassal2) load ] timeToRun.
>>>
>>> with and without an open SystemBrowser. But the load time and
>>> memory consumption is the same.
>>>
>>>
>>> Nicolai
>>>
>>>
>>>
>>
>>
>>
>>
> --
> Thierry Goubier
> CEA list
> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
> 91191 Gif sur Yvette Cedex
> France
> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
>
>
