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