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
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Ben,
You are raising an interesting point. Having a wrapper for a collection would greatly simplify the construction of the Roassal API. For example, we could then have: (ROElements forCollection: (1 to: 20)) addInteraction: RODraggable.
Currently we need to do: (ROElements forCollection: (1 to: 20)) do: [ :el | el addInteraction: RODraggable ].
Alexandre
On Aug 21, 2013, at 10:18 AM, Ben Coman btc@openInWorld.com wrote:
Alexandre Bergel wrote:
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@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.
Hi Mathieu, Just a random thought that pops into my head (and I don't know how practical it is....) Rather than concatenate the nodes and edges collections, could you have a class ROElemementsAndEdgesCollection holding the two collections as their separate entities and to iterate as follows...
ROElemementsAndEdgesCollection >> do: aBlock nodes do: aBlock edges do: aBlock
cheers, Ben
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Ben Coman -
mathieubmddehouck＠mailoo.org