7:56 a.m.
Hi,
I committed another small change that has a significant impact on the
speed of Groups and especially the Moose Finder.
We used to have:
RuntimeStorage>>elements
^self asArray
Now we have
RuntimeStorage>>elements
^elements
In other words, we are not returning an Array but the original
OrderedCollection. This makes up for a significant speed improvement
when having large models. Tests are green, but if you encounter
problems, please let me know.
In any case, I noticed that we are actually using the storage of a
group in a wrong way. We should always use the storage which is
already a collection instead of directly using the entities of a group.
Cheers,
Doru
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of
problem understanding."
10:21 a.m.
On Aug 5, 2010, at 7:56 AM, Tudor Girba wrote:
Hi,
I committed another small change that has a significant impact on the speed of Groups and
especially the Moose Finder.
We used to have:
RuntimeStorage>>elements
^self asArray
Now we have
RuntimeStorage>>elements
^elements
In other words, we are not returning an Array but the original OrderedCollection. This
makes up for a significant speed improvement when having large models. Tests are green,
but if you encounter problems, please let me know.
In any case, I noticed that we are actually using the storage of a group in a wrong way.
We should always use the storage which is already a collection instead of directly using
the entities of a group.
you lost me on that one: can you explain.
Cheers,
Doru
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem
understanding."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:30 a.m.
Hi,
On 5 Aug 2010, at 10:21, Stéphane Ducasse wrote:
On Aug 5, 2010, at 7:56 AM, Tudor Girba wrote:
> Hi,
>
> I committed another small change that has a significant impact on
> the speed of Groups and especially the Moose Finder.
>
> We used to have:
> RuntimeStorage>>elements
> ^self asArray
>
> Now we have
> RuntimeStorage>>elements
> ^elements
>
> In other words, we are not returning an Array but the original
> OrderedCollection. This makes up for a significant speed
> improvement when having large models. Tests are green, but if you
> encounter problems, please let me know.
>
> In any case, I noticed that we are actually using the storage of a
> group in a wrong way. We should always use the storage which is
> already a collection instead of directly using the entities of a
> group.
you lost me on that one: can you explain.
We have
MooseAbstractGroup>>entities
^ self entityStorage elements
EntityStorage that is a subclass of Collection. When we use
MooseEntity>>entities, we possibly ask for some conversion (for
example, before we converted to Array in RuntimeStorage) and this can
be expensive. Instead, internally we should always go through the
entityStorage to delegate to the EntityStorage and then rely on that
implementation.
Is that clearer?
Doru
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "Problem solving efficiency grows with the abstractness level of
> problem understanding."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Be rather willing to give than demanding to get."
10:34 a.m.
>>
>>
>> In any case, I noticed that we are actually using the storage of a group in a
wrong way. We should always use the storage which is already a collection instead of
directly using the entities of a group.
>
>
> you lost me on that one: can you explain.
We have
MooseAbstractGroup>>entities
^ self entityStorage elements
EntityStorage that is a subclass of Collection. When we use MooseEntity>>entities,
we possibly ask for some conversion (for example, before we converted to Array in
RuntimeStorage) and this can be expensive. Instead, internally we should always go through
the entityStorage to delegate to the EntityStorage and then rely on that implementation.
Is that clearer?
Can you show an example of what we did wrong and what we should do because I'm not
100% sure I fully understand
What is MooseEntity>>entities definition
Doru
>
>>
>> Cheers,
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "Problem solving efficiency grows with the abstractness level of problem
understanding."
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Be rather willing to give than demanding to get."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
12:01 p.m.
Hi,
>>> In any case, I noticed that we are actually using the
storage of
>>> a group in a wrong way. We should always use the storage which is
>>> already a collection instead of directly using the entities of a
>>> group.
>>
>>
>> you lost me on that one: can you explain.
>
> We have
>
> MooseAbstractGroup>>entities
> ^ self entityStorage elements
>
> EntityStorage that is a subclass of Collection. When we use
> MooseEntity>>entities, we possibly ask for some conversion (for
> example, before we converted to Array in RuntimeStorage) and this
> can be expensive. Instead, internally we should always go through
> the entityStorage to delegate to the EntityStorage and then rely on
> that implementation.
>
> Is that clearer?
Can you show an example of what we did wrong and what we should do
because I'm not 100% sure I fully understand
What is MooseEntity>>entities definition
Sorry it was supposed to be MooseAbstractGroup>>entities instead of
MooseEntity>>entities.
As I said, this is implemented like:
MooseAbstractGroup>>entities
^ self entityStorage elements
This means that when I call entities, I do not get the entityStorage
(which is the collection) but the internal implementation of it.
Take a look at the following:
MooseAbstractGroup>>asOrderedCollection
^ self entities asOrderedCollection
This means that I first retrieve the elements and then I transform.
So:
- either we do not use entities but only entityStorage (at least
internally), or
- or we just make entities to return the storage.
I would tend to go the second route, but I am not yet sure of the
implications.
Is this better? :)
Doru
>
> Doru
>
>>
>>>
>>> Cheers,
>>> Doru
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Problem solving efficiency grows with the abstractness level of
>>> problem understanding."
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Be rather willing to give than demanding to get."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
4870
days inactive
4870
days old
4 comments
2 participants
participants (2)
-
Stéphane Ducasse -
Tudor Girba