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.
I also thought about that. But Let wait to see that accessing the cache dictionary is really a problem. Having a cache object instead of a dictionary will require to have
Alexandre
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