Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo
Le 27/06/2014 13:02, Goubier Thierry a écrit :
Ok then, a simple profile should do it.
Sort of, it doesn't show up that clearly.
I'll have a look.
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 did profile loading Roassal2 with AltBrowser yesterday evening and updates on the browser take 15% of the execution time... Will optimize that.
Went from 15% to 2~3% of Roassal2 loading time :) Thierry -- 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
On 27 Jun 2014, at 14:00, Goubier Thierry <thierry.goubier@cea.fr> 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
My guess would then be: when updating the list of packages, the selected morph isn't removed from selectedMorphs, however the tree view is rebuilt [*] by recreating all models and all morphs inside, with reselection of the current package (which sees a newly created morph selected and added to selectedMorphs). [*] Yes, on average, what is done when a tree is updated is : destroy all morphs inside the tree view, and all models as well, and recreates everything. Now, why on AltBrowser tree view I haven't seen the issue: single selection versus multiple selection? Or because I have some code to do partial tree updates? We're lacking a nice tree object model for GUI use. I'll try to write a test case tracking this. Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Johan Brichau [johan@inceptive.be] Envoyé : dimanche 29 juin 2014 22:31 à : Pharo Development List Objet : Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo On 27 Jun 2014, at 14:00, Goubier Thierry <thierry.goubier@cea.fr> 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
2014-06-29 22:31 GMT+02:00 Johan Brichau <johan@inceptive.be>:
On 27 Jun 2014, at 14:00, Goubier Thierry <thierry.goubier@cea.fr> 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
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 <nicolaihess@web.de> wrote:
2014-06-29 22:31 GMT+02:00 Johan Brichau <johan@inceptive.be>:
On 27 Jun 2014, at 14:00, Goubier Thierry <thierry.goubier@cea.fr> 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
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.
My test sequence: open PackageTreeNautilus, select a package. Then the following script with the values: PackageTreePackageNodeModel allInstances size. 313. (ConfigurationOfSmaCC project version: #stable) load. Smalltalk garbageCollect. PackageTreePackageNodeModel allInstances size. 14215 I don't track MorphTreeNodeMorph because AltBrowser uses them as well. SmaCC is around 10 packages. Thierry
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 <nicolaihess@web.de> wrote:
2014-06-29 22:31 GMT+02:00 Johan Brichau <johan@inceptive.be>:
On 27 Jun 2014, at 14:00, Goubier Thierry <thierry.goubier@cea.fr> 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
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 <nicolaihess@web.de> wrote:
2014-06-29 22:31 GMT+02:00 Johan Brichau <johan@inceptive.be>:
On 27 Jun 2014, at 14:00, Goubier Thierry <thierry.goubier@cea.fr> 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
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 <thierry.goubier@cea.fr>:
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 <nicolaihess@web.de> wrote:
2014-06-29 22:31 GMT+02:00 Johan Brichau <johan@inceptive.be>:
On 27 Jun 2014, at 14:00, Goubier Thierry <thierry.goubier@cea.fr> 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
It would solve the selection kept while updating the full list, but it won't solve partial updates. You would also be apparently deselecting and reselecting when appending elements to the list. Thierry Le 30/06/2014 16:15, Nicolai Hess a écrit :
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 <thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr>>:
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 <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
2014-06-29 22:31 GMT+02:00 Johan Brichau <johan@inceptive.be <mailto:johan@inceptive.be>>:
On 27 Jun 2014, at 14:00, Goubier Thierry <thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr>> 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 <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95
-- 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
Le 30/06/2014 09:09, Nicolai Hess a écrit :
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.
I let you as an exercise write the necessary code to do a partial update of the displayed tree :) Don't forget to remember which nodes were expanded and which were not.
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.
This is the Nautilus approach. You don't have to do it that way.
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.
Select a package in Nautilus first. Thierry -- 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
participants (4)
-
GOUBIER Thierry -
Goubier Thierry
-
Johan Brichau -
Nicolai Hess