19 Jun
2010
19 Jun
'10
8:02 a.m.
Hi Doru,
On Jun 18, 2010, at 22:31 , Tudor Girba wrote:
Hi Jannik,
As I mentioned in two mails I sent in the past week, you cannot store anything in the
Shape because a Shape is just a specification that is shared among multiple graph
Elements. Thus, the state must be stored in the Elements. At the moment this is achieved
by the means of a dictionary (see MOGraphElement>>attributeAt: and friends).
Ahah, yes, I did not read previous mail....
But if a shape is shared, how is computed "aShape model" ? There is something I
do not understand, really....
Of course, we could also create an InstanceShape that has actual instance variables, but
that would have only limited impact.
I do not understand why ?
We use the same approach to store extension variables
in Moose Entities and that works just fine.
Yes but there is a difference: in moose entities, main variables are stored in the state
of the object, then we extend it and store in a dictionary other things.
Now, maybe I missed something, but why do you say that the current cache is global?
Where do I say that ? :)
Cheers,
Jannik
Cheers,
Doru
On 18 Jun 2010, at 22:17, Laval Jannik wrote:
---
Jannik Laval
Hi Alex,
There is something I do not understand.
Why do you use a cache and not the state of the object ?
Isn't it more efficient to store values in instance variable instead of a cache
construct with a collection, or another complex structure.
I'm sure you use cache for good reasons,
and maybe my vision is too naive.
But we have several problems which will appear in a near future:
- if we do not use cache, visualization is slow.
- if we use a cache, the space used by pharo will explode (for now, in a vm with original
parameters, it is not possible to load 7 times the MooseModel of Moose itself)
Now, if we have a state for a shape, there are no problem of cache or of refresh.
But as I said before, my vision is maybe too naive.
Please, explain your choice :)
Thank you
Cheers,
Jannik
PS: for a result, eDSM is always slow, so some parameters are not cached anymore ?
On Jun 18, 2010, at 14:50 , Alexandre Bergel wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Alex, do
you cache all things ?
All the parameters in a shape that could be cached are now cached (e.g., width: height:
fillColor: borderColor: ...)
Cheers,
Alexandre
Thanks,
Jannik
On Jun 17, 2010, at 17:47 , Tudor Girba wrote:
> I tested on a regular DSM with 259 namespaces and I can now properly scroll once it
gets displayed.
>
> Jannik, Veronica, could you check in your cases?
>
> Cheers,
> Doru
>
>
>
> On 17 Jun 2010, at 16:30, Tudor Girba wrote:
>
>> Hi Alex,
>>
>>>> Indeed, this caching should happen for all properties and for all shapes
(both for nodes and for edges). I think that Alex stopped in the middle because he did not
know whether this caching had an effect or not.
>>>
>>> I was wondering whether it would make sense to do this for all the metrics.
Apparently yes, I then continued. All shape parameters should be cached.
>>>> Alex, could you take a look at that?
>>>
>>> Done. Mondrian-Alexandre_Bergel.470
>>
>> Great. I checked a bit the implementation, and I would only suggest to check for
isCached in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>>
>>>> The next question is that if the border color is called all the time,
what is the use of the bitmap cache?
>>>
>>> The bitmap is for not having to display inner nodes. Recursion takes times.
>>
>> I know, but if you compute it once why do you still need to re-render?
>>
>> Cheers,
>> Doru
>>
>>
>>
>>>>> ======
>>>>> |view o |
>>>>> view := MOViewRenderer new.
>>>>> o := OrderedCollection new: 100.
>>>>> 1 to: 100 do:[:i | o add: i].
>>>>> (view shape: (MORectangleShape new
>>>>> width: [:e | 200];
>>>>> height: 200;
>>>>> withBorder;
>>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>>>> view nodes: o.
>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>> view open
>>>>> ======
>>>
>>> A better version could be
>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>> |view o a |
>>> a := {0}.
>>> view := MOViewRenderer new.
>>> o := OrderedCollection new: 100.
>>> 1 to: 100 do:[:i | o add: i].
>>> (view shape: (MORectangleShape new
>>> width: [:e | 200];
>>> height: 200;
>>> withBorder;
>>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>>> view nodes: o.
>>> view layout: (MOGridLayout new gapSize: 1).
>>> view open.
>>> a
>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>
>>> Just inspect the expression, and see if the array a changes over the time.
>>>
>>> Is there any remaining problem left in Mondrian related to the speed issue?
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>
> --
> www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
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