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).
Of course, we could also create an InstanceShape that has actual
instance variables, but that would have only limited impact. We use
the same approach to store extension variables in Moose Entities and
that works just fine.
Now, maybe I missed something, but why do you say that the current
cache is global?
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