Slitting the collection seems to bring many problems. I have also share with you that
splitting the collection is a good thing. But well.. if it implies a severe refactoring,
it does not look that appealing to do it now.
Alexandre
On Jul 24, 2013, at 6:50 AM, mathieubmddehouck(a)mailoo.org wrote:
Hi
An idea to improve roassal scalability was to split the collection elements belonging to
ROContainers and builder, into two different collections : edges and nodes.
It would permit not to unset shape after we add new edges or nodes, and it would save
little time when asking for elementsNotEdges.
But after a little trial, it seems that it will ask a huge refactor of roassal to see a
real gain in time, with just splitting the collection it gets worse.
For example, each time we need both nodes and edges in the same collection we have to
concatenate the new collections and it's time consuming.
Always working with Object withAllSubclasses as benchmark, we spend 28 second in
copyReplaceFrom:to:with ( concatenation ).
And it brings us from 69 sec to 136 sec... A beautiful loss of 67 seconds...
The idea came when using rawEdgesFrom:to: was long, in fact it used to call
elementsNotEdges for each iteration, then in our case a little more than 11000 times, and
that was long, but now, as we don't call it so often it is quick enough.
That was maybe not that a good idea to split the collection.
Tell me what you think.
Regards
Mathieu
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.