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:
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval