1 Dec
2009
1 Dec
'09
8:50 p.m.
Hi Simon,
The forRuntime is actually supposed to be an optimization that comes
from the VW time. However, I do not know if it holds true in Pharo.
The groupedBy: sounds like a possible problem indeed.
What was the VM trick?
Cheers,
Doru
On 1 Dec 2009, at 20:01, Simon Denier wrote:
On 1 déc. 2009, at 12:17, Simon Denier wrote:
--
www.tudorgirba.com
"Value is always contextual."
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