Thank you Doru for your answers.
Now I understand better the behaviors of Mondrian.
So, if we come back the the original problem....
eDSM is still slow.
If Mondrian has cache, I do not understand what is the problem now.
The sole thing I do is the method MOEdge>>edgesDsm: aCollection from: aFromBlock to:
aToBlock
where I am sure of the placement of edges for eDSM.
Cheers,
Jannik
On Jun 19, 2010, at 10:03 , 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....
Let's take an example: a Node with a RectangleShape. The shape of this particular
node is drawn in:
MOShape>>display: anElement on: aCanvas
So, the RectangleShape will override this method and then it will draw the actual shape
based on the given anElement. For example, the height of the rectangle is computed like:
MOBoundedShape>>heightFor: anElement
^ anElement
cachedNamed: #cacheheightFor:
ifAbsentInitializeWith: [ self computeHeightFor: anElement ]
So, the actual value is retrieved from anElement. So, you will have a state per element,
which is what is wanted.
>> 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 ?
I said that if you want to store explicit instance variables instead of a dictionary, you
have to create a class that stores the values for each shape instance. So, in our example,
we could have:
MOGraphElement>>shapeInstance
^ shapeInstance ifNil: [shapeInstance := self shape instanceFor: self]
and then have an MORectangleShapeInstance that stores actual values in instance variables
like height, width etc.
>> 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.
No real difference. The extensions of the meta-model store instance variables. For
example, the Java extensions store instance variables related to annotations (in
FAMIXEntity) or exceptions (in FAMIXMethod). This should work reasonably well for small
dictionaries, which is the case for storing instance variables.
>> Now, maybe I missed something, but why do you say that the current cache is
global?
>
> Where do I say that ? :)
Well, you said that because of the cache, we need to invalidate it. But that only happens
when you have a global cache. In our case, as soon as you close the window, the cache is
gone.
Cheers,
Doru
> Cheers,
> Jannik
>>
>> Cheers,
>> Doru
>>
>>
>> On 18 Jun 2010, at 22:17, Laval Jannik wrote:
>>
>>> 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:
>>>
>>>>> 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
>>>
>>> ---
>>> 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
>
> ---
> 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 now and then stop and ask yourself if the war you're fighting is the
right one."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev