24 Jul
2013
24 Jul
'13
12:50 p.m.
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
28 Jul
28 Jul
5:23 p.m.
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
26 Aug
26 Aug
12:12 a.m.
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(a)openInWorld.com> wrote:
Alexandre Bergel wrote:
_______________________________________________
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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.
>
>
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4136
days inactive
4169
days old
4 comments
3 participants
participants (3)
-
Alexandre Bergel -
Ben Coman -
mathieubmddehouck＠mailoo.org