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