18 Jun
2010
18 Jun
'10
10:17 p.m.
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
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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