2 Dec
2009
2 Dec
'09
12:28 p.m.
On Dec 1, 2009, at 8:38 PM, Alexandre Bergel wrote:
This is excellent Simon!
1 hour to import the whole Pharo is nothing.
Seriously 1 hour?
We can still import the complete VW in a couple of minutes in VW
Alexandre
On 1 Dec 2009, at 16:01, Simon Denier wrote:
On 1 déc. 2009, at 12:17, Simon Denier wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi there
I'm trying to assess bottlenecks in the Moose importer. I think there are some hidden
scalability issues especially in the InstallElementsOperator and the
CandidateListOperator.
Now I cant run a profiler on that because the image crashes before the end, so I just
randomly pick some interruption from time to time (especially when I dont have feedback by
a progress bar).
Some suspect code:
InstallElementsOperator >>basicRun
model entityStorage forSetup.
self container
do:
[:each |
model add: each.
self increment].
model entityStorage forRuntime <------- here: converting to a runtime storage takes
a long time
CandidateListOperator >>setUp
"dont call 'model allMethods' here because it sorts the group and we dont
care at this level"
groups := ((model allWithType: FAMIXMethod) reject: #isAbstract) groupedBy: #signature
<----- groupedBy: create a dictionary with all method signatures, I suspect it becomes
inefficient on large models
Any taker/suggestion on this?
-----------------------------
Also I think it would be good to launch the importer in a separate/background thread,
with the possibility to cancel it.
What we can do basically (for example):
[MooseScripts createModelForPharo] forkAt: 20 (give it a low priority to not starve other
process, esp. UI)
and we can still interrupt the process in
ok so it finally works in less than one hour (pharo 10493 dev image). Thanks to Jannik
for the tip on increasing VM memory at start up (it's strange that it didnt complain
about low memory in previous runs), it was the key.
Running in a separate thread is also a good idea and the UI is still responsive despite
the heavy computation. I think I will open a request for enhancement :)
As said, there is something to be done on the methods above. Perhaps it's just the
lack of feedback, but computing candidates feels faster than installing/setting up the
model for that.
So here is a picture of 142 packages in pharo 10493, with packages belonging to the same
big cycle sharing the same color
<PharoPackageCycles.png>
Now if someone knowledgeable in Morphic can come with an enhanced progress bar with a
cancel button, which would terminate the import process when clicked.
--
Simon
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev