Hi all,
I localized the bug of Mondrian, As Alex said, width and height are stored in cache, so a script like this work fine:
====== |view o | view := MOViewRenderer new. o := OrderedCollection new: 100. 1 to: 100 do:[:i | o add: i]. (view shape: (MORectangleShape new width: [:e | (Delay forMilliseconds: 50) wait. 200]; height: 200; withBorder; borderColor: [:e | Color gray])). view nodes: o. view layout: (MOGridLayout new gapSize: 1). view open ======
It is slow to generate, then it scroll well.
Now, if I do the same thing with a Delay in the block of borderColor:, the visualization is dead. ====== |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 ======
This is the bug we have in Blueprint, in eDSM and all the visualization we made. I think shapes should keep these state and maybe react to announcement.
Cheers, --- Jannik Laval
Brilliant!
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.
Alex, could you take a look at that?
The next question is that if the border color is called all the time, what is the use of the bitmap cache?
Cheers, Doru
On 16 Jun 2010, at 10:22, Laval Jannik wrote:
Hi all,
I localized the bug of Mondrian, As Alex said, width and height are stored in cache, so a script like this work fine:
====== |view o | view := MOViewRenderer new. o := OrderedCollection new: 100. 1 to: 100 do:[:i | o add: i]. (view shape: (MORectangleShape new width: [:e | (Delay forMilliseconds: 50) wait. 200]; height: 200; withBorder; borderColor: [:e | Color gray])). view nodes: o. view layout: (MOGridLayout new gapSize: 1). view open ======
It is slow to generate, then it scroll well.
Now, if I do the same thing with a Delay in the block of borderColor:, the visualization is dead. ====== |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 ======
This is the bug we have in Blueprint, in eDSM and all the visualization we made. I think shapes should keep these state and maybe react to announcement.
Cheers,
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"When people care, great things can happen."
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
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.
====== |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
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."
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."
Johan also saw an improvement in AspectsMap
This is cool to have discussed about this.
Alexandre
On 17 Jun 2010, at 11: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
Yes, AspectMapS ( :-P ) also sees the speedup. There is a problem with the zoom though, but Alex is already working on it :-)
On 17 Jun 2010, at 14:34, Alexandre Bergel wrote:
Johan also saw an improvement in AspectsMap
This is cool to have discussed about this.
Alexandre
On 17 Jun 2010, at 11: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
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
excellent we were not aware that the properties were not cached else we would have produce a delay long time ago
On Jun 17, 2010, at 8:50 PM, Johan Fabry wrote:
Yes, AspectMapS ( :-P ) also sees the speedup. There is a problem with the zoom though, but Alex is already working on it :-)
On 17 Jun 2010, at 14:34, Alexandre Bergel wrote:
Johan also saw an improvement in AspectsMap
This is cool to have discussed about this.
Alexandre
On 17 Jun 2010, at 11: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
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
Doru, do you do a DSM or a eDSM ? With a eDSM, I do not see difference, I think there are some computation somewhere else. Alex, do you cache all things ?
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
Hi Jannik,
I tried a DSM. The eDSM gives me a subscript out of bounds error somewhere deep in the contentOfCell: aView for: aCell with: aPackage out: aBoolean method.
I applied this on the namespaces of JUnit. I attached the debug log.
Cheers, Doru
On 18 Jun 2010, at 07:19, Laval Jannik wrote:
Hi,
Doru, do you do a DSM or a eDSM ? With a eDSM, I do not see difference, I think there are some computation somewhere else. Alex, do you cache all things ?
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
-- www.tudorgirba.com
"It's not how it is, it is how we see it."
Strange, it seems to be in a at:. I use it only to get the class name. Do you have some classes without name or with a name with size < 2 ?
I change the code, now it should work.
Cheers, Jannik
On Jun 18, 2010, at 11:53 , Tudor Girba wrote:
Hi Jannik,
I tried a DSM. The eDSM gives me a subscript out of bounds error somewhere deep in the contentOfCell: aView for: aCell with: aPackage out: aBoolean method.
I applied this on the namespaces of JUnit. I attached the debug log.
Cheers, Doru
<debug.log> On 18 Jun 2010, at 07:19, Laval Jannik wrote:
Hi,
Doru, do you do a DSM or a eDSM ? With a eDSM, I do not see difference, I think there are some computation somewhere else. Alex, do you cache all things ?
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
-- www.tudorgirba.com
"It's not how it is, it is how we see it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
strange models sometimes you cannot rely on the data extracted. On Jun 18, 2010, at 4:41 PM, Laval Jannik wrote:
Strange, it seems to be in a at:. I use it only to get the class name. Do you have some classes without name or with a name with size < 2 ?
I change the code, now it should work.
Cheers, Jannik
On Jun 18, 2010, at 11:53 , Tudor Girba wrote:
Hi Jannik,
I tried a DSM. The eDSM gives me a subscript out of bounds error somewhere deep in the contentOfCell: aView for: aCell with: aPackage out: aBoolean method.
I applied this on the namespaces of JUnit. I attached the debug log.
Cheers, Doru
<debug.log> On 18 Jun 2010, at 07:19, Laval Jannik wrote:
Hi,
Doru, do you do a DSM or a eDSM ? With a eDSM, I do not see difference, I think there are some computation somewhere else. Alex, do you cache all things ?
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
-- www.tudorgirba.com
"It's not how it is, it is how we see it."
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
Hi,
The inFusion parser gets the anonymous classes with just numbers. So, you can have class named #1. You should basically get that in any Java model parsed with inFusion.
Cheers, Doru
On 18 Jun 2010, at 19:11, Stéphane Ducasse wrote:
strange models sometimes you cannot rely on the data extracted. On Jun 18, 2010, at 4:41 PM, Laval Jannik wrote:
Strange, it seems to be in a at:. I use it only to get the class name. Do you have some classes without name or with a name with size < 2 ?
I change the code, now it should work.
Cheers, Jannik
On Jun 18, 2010, at 11:53 , Tudor Girba wrote:
Hi Jannik,
I tried a DSM. The eDSM gives me a subscript out of bounds error somewhere deep in the contentOfCell: aView for: aCell with: aPackage out: aBoolean method.
I applied this on the namespaces of JUnit. I attached the debug log.
Cheers, Doru
<debug.log> On 18 Jun 2010, at 07:19, Laval Jannik wrote:
Hi,
Doru, do you do a DSM or a eDSM ? With a eDSM, I do not see difference, I think there are some computation somewhere else. Alex, do you cache all things ?
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
-- www.tudorgirba.com
"It's not how it is, it is how we see it."
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
-- www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be done."
Hi Doru,
Could you try a eDSM? It should work.
Thank you for the bug report :)
Cheers, Jannik
On Jun 18, 2010, at 20:13 , Tudor Girba wrote:
Hi,
The inFusion parser gets the anonymous classes with just numbers. So, you can have class named #1. You should basically get that in any Java model parsed with inFusion.
Cheers, Doru
On 18 Jun 2010, at 19:11, Stéphane Ducasse wrote:
strange models sometimes you cannot rely on the data extracted. On Jun 18, 2010, at 4:41 PM, Laval Jannik wrote:
Strange, it seems to be in a at:. I use it only to get the class name. Do you have some classes without name or with a name with size < 2 ?
I change the code, now it should work.
Cheers, Jannik
On Jun 18, 2010, at 11:53 , Tudor Girba wrote:
Hi Jannik,
I tried a DSM. The eDSM gives me a subscript out of bounds error somewhere deep in the contentOfCell: aView for: aCell with: aPackage out: aBoolean method.
I applied this on the namespaces of JUnit. I attached the debug log.
Cheers, Doru
<debug.log> On 18 Jun 2010, at 07:19, Laval Jannik wrote:
Hi,
Doru, do you do a DSM or a eDSM ? With a eDSM, I do not see difference, I think there are some computation somewhere else. Alex, do you cache all things ?
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
-- www.tudorgirba.com
"It's not how it is, it is how we see it."
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
-- www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be done."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
Yep, now it works :)
Doru
On 18 Jun 2010, at 20:28, Laval Jannik wrote:
Hi Doru,
Could you try a eDSM? It should work.
Thank you for the bug report :)
Cheers, Jannik
On Jun 18, 2010, at 20:13 , Tudor Girba wrote:
Hi,
The inFusion parser gets the anonymous classes with just numbers. So, you can have class named #1. You should basically get that in any Java model parsed with inFusion.
Cheers, Doru
On 18 Jun 2010, at 19:11, Stéphane Ducasse wrote:
strange models sometimes you cannot rely on the data extracted. On Jun 18, 2010, at 4:41 PM, Laval Jannik wrote:
Strange, it seems to be in a at:. I use it only to get the class name. Do you have some classes without name or with a name with size < 2 ?
I change the code, now it should work.
Cheers, Jannik
On Jun 18, 2010, at 11:53 , Tudor Girba wrote:
Hi Jannik,
I tried a DSM. The eDSM gives me a subscript out of bounds error somewhere deep in the contentOfCell: aView for: aCell with: aPackage out: aBoolean method.
I applied this on the namespaces of JUnit. I attached the debug log.
Cheers, Doru
<debug.log> On 18 Jun 2010, at 07:19, Laval Jannik wrote:
Hi,
Doru, do you do a DSM or a eDSM ? With a eDSM, I do not see difference, I think there are some computation somewhere else. Alex, do you cache all things ?
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
-- www.tudorgirba.com
"It's not how it is, it is how we see it."
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
-- www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be done."
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
"Live like you mean it."
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
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
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@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."
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
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."
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
Hi All,
I do a "profile all UI" and a scroll in a eDSM. The eDSM has been built on MooseModel of Moose itself and made with the 77 model packages.
I hope the result can help. Results follows:
============ -------------------------------- Process: (40s) 211550208: nil -------------------------------- 58.7% {12320ms} WorldState>>doOneCycleFor: 56.8% {11921ms} WorldState>>doOneCycleNowFor: |54.9% {11522ms} WorldState>>displayWorldSafely: | |54.9% {11522ms} PasteUpMorph>>displayWorld | | 54.9% {11522ms} PasteUpMorph>>privateOuterDisplayWorld | | 54.9% {11522ms} WorldState>>displayWorld:submorphs: | | 54.9% {11522ms} WorldState>>drawWorld:submorphs:invalidAreasOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} StandardWindow(Morph)>>fullDrawOn: | | 54.9% {11522ms} StandardWindow(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} ScrollPane(Morph)>>fullDrawOn: | | 54.9% {11522ms} ScrollPane(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} TransformMorph(Morph)>>fullDrawOn: | | 54.8% {11501ms} TransformMorph>>drawSubmorphsOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDraw: | | 54.8% {11501ms} MOCanvas(Morph)>>fullDrawOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>drawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>draw: | | 54.8% {11501ms} MOCanvas>>drawOn: | | 54.8% {11501ms} MORoot(MONode)>>displayOn: | | 30.9% {6485ms} MONode>>displayOn: | | |18.1% {3799ms} MOEdge>>displayOn: | | | |17.1% {3589ms} MOStraightLineShape>>display:on: | | | | 5.8% {1217ms} FormCanvas>>line:to:width:color: | | | | |2.9% {609ms} FormCanvas>>setFillColor: | | | | | |1.4% {294ms} GrafPort>>fillPattern: | | | | | | 1.2% {252ms} GrafPort(BitBlt)>>fillColor: | | | | |1.1% {231ms} GrafPort(BitBlt)>>drawFrom:to: | | | | 3.3% {693ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |3.1% {651ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 2.7% {567ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.9% {399ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.2% {252ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.5% {525ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |2.3% {483ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 1.7% {357ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.5% {315ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.1% {231ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.3% {483ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | | |1.9% {399ms} MONode(MOGraphElement)>>isNotSelected | | | | | 1.3% {273ms} MONode(MOGraphElement)>>isSelected | | | | 1.1% {231ms} Point>>abs | | |12.2% {2561ms} MONode>>displayOn: | | | 8.4% {1763ms} MOEdge>>displayOn: | | | |8.0% {1679ms} MOStraightLineShape>>display:on: | | | | 2.6% {546ms} FormCanvas>>line:to:width:color: | | | | |1.3% {273ms} FormCanvas>>setFillColor: | | | | 1.5% {315ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |1.4% {294ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 1.3% {273ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.3% {273ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |1.2% {252ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.1% {231ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | 2.9% {609ms} MONode>>displayOn: | | | 2.1% {441ms} MOEdge>>displayOn: | | | 2.0% {420ms} MOStraightLineShape>>display:on: | | 23.4% {4911ms} MOEdge>>displayOn: | | 22.0% {4617ms} MOStraightLineShape>>display:on: | | 7.5% {1574ms} FormCanvas>>line:to:width:color: | | |3.5% {735ms} FormCanvas>>setFillColor: | | | |1.7% {357ms} GrafPort>>fillPattern: | | | | 1.5% {315ms} GrafPort(BitBlt)>>fillColor: | | | | 1.2% {252ms} DisplayScreen(Form)>>bitPatternFor: | | |1.4% {294ms} GrafPort(BitBlt)>>drawFrom:to: | | 3.9% {819ms} MOStraightLineShape(MOLineShape)>>colorFor: | | |3.7% {777ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | 3.2% {672ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.4% {504ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.3% {273ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | 3.5% {735ms} MOStraightLineShape(MOLineShape)>>widthFor: | | |3.1% {651ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.3% {483ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.5% {315ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | 1.0% {210ms} IdentityDictionary>>scanFor: | | 3.1% {651ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | |2.6% {546ms} MONode(MOGraphElement)>>isNotSelected | | | 1.7% {357ms} MONode(MOGraphElement)>>isSelected | | 1.4% {294ms} Point>>abs ==============
Cheers, Jannik
Hi Jannik,
From this trace, it looks like the time is spent on rendering.
I understand it is still slow, but did you notice any improvement since the caching? When I tried eDSM, it looked significantly faster. I mean before I could not scroll at all, now I can even if only slowly. Could you confirm this?
Cheers, Doru
On 19 Jun 2010, at 14:25, Laval Jannik wrote:
Hi All,
I do a "profile all UI" and a scroll in a eDSM. The eDSM has been built on MooseModel of Moose itself and made with the 77 model packages.
I hope the result can help. Results follows:
============
Process: (40s) 211550208: nil
58.7% {12320ms} WorldState>>doOneCycleFor: 56.8% {11921ms} WorldState>>doOneCycleNowFor: |54.9% {11522ms} WorldState>>displayWorldSafely: | |54.9% {11522ms} PasteUpMorph>>displayWorld | | 54.9% {11522ms} PasteUpMorph>>privateOuterDisplayWorld | | 54.9% {11522ms} WorldState>>displayWorld:submorphs: | | 54.9% {11522ms} WorldState>>drawWorld:submorphs:invalidAreasOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} StandardWindow(Morph)>>fullDrawOn: | | 54.9% {11522ms} StandardWindow(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} ScrollPane(Morph)>>fullDrawOn: | | 54.9% {11522ms} ScrollPane(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} TransformMorph(Morph)>>fullDrawOn: | | 54.8% {11501ms} TransformMorph>>drawSubmorphsOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDraw: | | 54.8% {11501ms} MOCanvas(Morph)>>fullDrawOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>drawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>draw: | | 54.8% {11501ms} MOCanvas>>drawOn: | | 54.8% {11501ms} MORoot(MONode)>>displayOn: | | 30.9% {6485ms} MONode>>displayOn: | | |18.1% {3799ms} MOEdge>>displayOn: | | | |17.1% {3589ms} MOStraightLineShape>>display:on: | | | | 5.8% {1217ms} FormCanvas>>line:to:width:color: | | | | |2.9% {609ms} FormCanvas>>setFillColor: | | | | | | 1.4% {294ms} GrafPort>>fillPattern: | | | | | | 1.2% {252ms} GrafPort(BitBlt)>>fillColor: | | | | |1.1% {231ms} GrafPort(BitBlt)>>drawFrom:to: | | | | 3.3% {693ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |3.1% {651ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 2.7% {567ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.9% {399ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.2% {252ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.5% {525ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |2.3% {483ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 1.7% {357ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.5% {315ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.1% {231ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.3% {483ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | | |1.9% {399ms} MONode(MOGraphElement)>>isNotSelected | | | | | 1.3% {273ms} MONode(MOGraphElement)>>isSelected | | | | 1.1% {231ms} Point>>abs | | |12.2% {2561ms} MONode>>displayOn: | | | 8.4% {1763ms} MOEdge>>displayOn: | | | |8.0% {1679ms} MOStraightLineShape>>display:on: | | | | 2.6% {546ms} FormCanvas>>line:to:width:color: | | | | | 1.3% {273ms} FormCanvas>>setFillColor: | | | | 1.5% {315ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | | 1.4% {294ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 1.3% {273ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.3% {273ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | | 1.2% {252ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.1% {231ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | 2.9% {609ms} MONode>>displayOn: | | | 2.1% {441ms} MOEdge>>displayOn: | | | 2.0% {420ms} MOStraightLineShape>>display:on: | | 23.4% {4911ms} MOEdge>>displayOn: | | 22.0% {4617ms} MOStraightLineShape>>display:on: | | 7.5% {1574ms} FormCanvas>>line:to:width:color: | | |3.5% {735ms} FormCanvas>>setFillColor: | | | |1.7% {357ms} GrafPort>>fillPattern: | | | | 1.5% {315ms} GrafPort(BitBlt)>>fillColor: | | | | 1.2% {252ms} DisplayScreen(Form)>>bitPatternFor: | | |1.4% {294ms} GrafPort(BitBlt)>>drawFrom:to: | | 3.9% {819ms} MOStraightLineShape(MOLineShape)>>colorFor: | | |3.7% {777ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | 3.2% {672ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.4% {504ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.3% {273ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | 3.5% {735ms} MOStraightLineShape(MOLineShape)>>widthFor: | | |3.1% {651ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.3% {483ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.5% {315ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | 1.0% {210ms} IdentityDictionary>>scanFor: | | 3.1% {651ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | |2.6% {546ms} MONode(MOGraphElement)>>isNotSelected | | | 1.7% {357ms} MONode(MOGraphElement)>>isSelected | | 1.4% {294ms} Point>>abs ==============
Cheers, Jannik _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
On Jun 19, 2010, at 14:31 , Tudor Girba wrote:
Hi Jannik,
From this trace, it looks like the time is spent on rendering.
I understand it is still slow, but did you notice any improvement since the caching? When I tried eDSM, it looked significantly faster. I mean before I could not scroll at all, now I can even if only slowly. Could you confirm this?
My experience is not so faster: before I could scroll slowly, now I can scroll slowly. Maybe not as much as before, but the difference is not evident. I will do some experiment to see more.
Cheers, Jannik
Cheers, Doru
On 19 Jun 2010, at 14:25, Laval Jannik wrote:
Hi All,
I do a "profile all UI" and a scroll in a eDSM. The eDSM has been built on MooseModel of Moose itself and made with the 77 model packages.
I hope the result can help. Results follows:
============
Process: (40s) 211550208: nil
58.7% {12320ms} WorldState>>doOneCycleFor: 56.8% {11921ms} WorldState>>doOneCycleNowFor: |54.9% {11522ms} WorldState>>displayWorldSafely: | |54.9% {11522ms} PasteUpMorph>>displayWorld | | 54.9% {11522ms} PasteUpMorph>>privateOuterDisplayWorld | | 54.9% {11522ms} WorldState>>displayWorld:submorphs: | | 54.9% {11522ms} WorldState>>drawWorld:submorphs:invalidAreasOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} StandardWindow(Morph)>>fullDrawOn: | | 54.9% {11522ms} StandardWindow(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} ScrollPane(Morph)>>fullDrawOn: | | 54.9% {11522ms} ScrollPane(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} TransformMorph(Morph)>>fullDrawOn: | | 54.8% {11501ms} TransformMorph>>drawSubmorphsOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDraw: | | 54.8% {11501ms} MOCanvas(Morph)>>fullDrawOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>drawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>draw: | | 54.8% {11501ms} MOCanvas>>drawOn: | | 54.8% {11501ms} MORoot(MONode)>>displayOn: | | 30.9% {6485ms} MONode>>displayOn: | | |18.1% {3799ms} MOEdge>>displayOn: | | | |17.1% {3589ms} MOStraightLineShape>>display:on: | | | | 5.8% {1217ms} FormCanvas>>line:to:width:color: | | | | |2.9% {609ms} FormCanvas>>setFillColor: | | | | | |1.4% {294ms} GrafPort>>fillPattern: | | | | | | 1.2% {252ms} GrafPort(BitBlt)>>fillColor: | | | | |1.1% {231ms} GrafPort(BitBlt)>>drawFrom:to: | | | | 3.3% {693ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |3.1% {651ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 2.7% {567ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.9% {399ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.2% {252ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.5% {525ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |2.3% {483ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 1.7% {357ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.5% {315ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.1% {231ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.3% {483ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | | |1.9% {399ms} MONode(MOGraphElement)>>isNotSelected | | | | | 1.3% {273ms} MONode(MOGraphElement)>>isSelected | | | | 1.1% {231ms} Point>>abs | | |12.2% {2561ms} MONode>>displayOn: | | | 8.4% {1763ms} MOEdge>>displayOn: | | | |8.0% {1679ms} MOStraightLineShape>>display:on: | | | | 2.6% {546ms} FormCanvas>>line:to:width:color: | | | | |1.3% {273ms} FormCanvas>>setFillColor: | | | | 1.5% {315ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |1.4% {294ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 1.3% {273ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.3% {273ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |1.2% {252ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.1% {231ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | 2.9% {609ms} MONode>>displayOn: | | | 2.1% {441ms} MOEdge>>displayOn: | | | 2.0% {420ms} MOStraightLineShape>>display:on: | | 23.4% {4911ms} MOEdge>>displayOn: | | 22.0% {4617ms} MOStraightLineShape>>display:on: | | 7.5% {1574ms} FormCanvas>>line:to:width:color: | | |3.5% {735ms} FormCanvas>>setFillColor: | | | |1.7% {357ms} GrafPort>>fillPattern: | | | | 1.5% {315ms} GrafPort(BitBlt)>>fillColor: | | | | 1.2% {252ms} DisplayScreen(Form)>>bitPatternFor: | | |1.4% {294ms} GrafPort(BitBlt)>>drawFrom:to: | | 3.9% {819ms} MOStraightLineShape(MOLineShape)>>colorFor: | | |3.7% {777ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | 3.2% {672ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.4% {504ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.3% {273ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | 3.5% {735ms} MOStraightLineShape(MOLineShape)>>widthFor: | | |3.1% {651ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.3% {483ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.5% {315ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | 1.0% {210ms} IdentityDictionary>>scanFor: | | 3.1% {651ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | |2.6% {546ms} MONode(MOGraphElement)>>isNotSelected | | | 1.7% {357ms} MONode(MOGraphElement)>>isSelected | | 1.4% {294ms} Point>>abs ==============
Cheers, Jannik _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
This is true that it is not fast as it should be.
Consider: | view | view := MOViewRenderer new. view shape rectangle size: 180. view nodes: (1 to: 45 squared). view gridLayout. view open
This is much faster than DSM. There might be something wrong with the caches.
Alexandre
On 19 Jun 2010, at 08:43, Laval Jannik wrote:
On Jun 19, 2010, at 14:31 , Tudor Girba wrote:
Hi Jannik,
From this trace, it looks like the time is spent on rendering.
I understand it is still slow, but did you notice any improvement since the caching? When I tried eDSM, it looked significantly faster. I mean before I could not scroll at all, now I can even if only slowly. Could you confirm this?
My experience is not so faster: before I could scroll slowly, now I can scroll slowly. Maybe not as much as before, but the difference is not evident. I will do some experiment to see more.
Cheers, Jannik
Cheers, Doru
On 19 Jun 2010, at 14:25, Laval Jannik wrote:
Hi All,
I do a "profile all UI" and a scroll in a eDSM. The eDSM has been built on MooseModel of Moose itself and made with the 77 model packages.
I hope the result can help. Results follows:
============
Process: (40s) 211550208: nil
58.7% {12320ms} WorldState>>doOneCycleFor: 56.8% {11921ms} WorldState>>doOneCycleNowFor: |54.9% {11522ms} WorldState>>displayWorldSafely: | |54.9% {11522ms} PasteUpMorph>>displayWorld | | 54.9% {11522ms} PasteUpMorph>>privateOuterDisplayWorld | | 54.9% {11522ms} WorldState>>displayWorld:submorphs: | | 54.9% {11522ms} WorldState>>drawWorld:submorphs:invalidAreasOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} StandardWindow(Morph)>>fullDrawOn: | | 54.9% {11522ms} StandardWindow(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} ScrollPane(Morph)>>fullDrawOn: | | 54.9% {11522ms} ScrollPane(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} TransformMorph(Morph)>>fullDrawOn: | | 54.8% {11501ms} TransformMorph>>drawSubmorphsOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDraw: | | 54.8% {11501ms} MOCanvas(Morph)>>fullDrawOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>drawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>draw: | | 54.8% {11501ms} MOCanvas>>drawOn: | | 54.8% {11501ms} MORoot(MONode)>>displayOn: | | 30.9% {6485ms} MONode>>displayOn: | | |18.1% {3799ms} MOEdge>>displayOn: | | | |17.1% {3589ms} MOStraightLineShape>>display:on: | | | | 5.8% {1217ms} FormCanvas>>line:to:width:color: | | | | |2.9% {609ms} FormCanvas>>setFillColor: | | | | | |1.4% {294ms} GrafPort>>fillPattern: | | | | | | 1.2% {252ms} GrafPort(BitBlt)>>fillColor: | | | | |1.1% {231ms} GrafPort(BitBlt)>>drawFrom:to: | | | | 3.3% {693ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |3.1% {651ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 2.7% {567ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.9% {399ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.2% {252ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.5% {525ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |2.3% {483ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 1.7% {357ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.5% {315ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.1% {231ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.3% {483ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | | |1.9% {399ms} MONode(MOGraphElement)>>isNotSelected | | | | | 1.3% {273ms} MONode(MOGraphElement)>>isSelected | | | | 1.1% {231ms} Point>>abs | | |12.2% {2561ms} MONode>>displayOn: | | | 8.4% {1763ms} MOEdge>>displayOn: | | | |8.0% {1679ms} MOStraightLineShape>>display:on: | | | | 2.6% {546ms} FormCanvas>>line:to:width:color: | | | | |1.3% {273ms} FormCanvas>>setFillColor: | | | | 1.5% {315ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |1.4% {294ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 1.3% {273ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.3% {273ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |1.2% {252ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.1% {231ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | 2.9% {609ms} MONode>>displayOn: | | | 2.1% {441ms} MOEdge>>displayOn: | | | 2.0% {420ms} MOStraightLineShape>>display:on: | | 23.4% {4911ms} MOEdge>>displayOn: | | 22.0% {4617ms} MOStraightLineShape>>display:on: | | 7.5% {1574ms} FormCanvas>>line:to:width:color: | | |3.5% {735ms} FormCanvas>>setFillColor: | | | |1.7% {357ms} GrafPort>>fillPattern: | | | | 1.5% {315ms} GrafPort(BitBlt)>>fillColor: | | | | 1.2% {252ms} DisplayScreen(Form)>>bitPatternFor: | | |1.4% {294ms} GrafPort(BitBlt)>>drawFrom:to: | | 3.9% {819ms} MOStraightLineShape(MOLineShape)>>colorFor: | | |3.7% {777ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | 3.2% {672ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.4% {504ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.3% {273ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | 3.5% {735ms} MOStraightLineShape(MOLineShape)>>widthFor: | | |3.1% {651ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.3% {483ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.5% {315ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | 1.0% {210ms} IdentityDictionary>>scanFor: | | 3.1% {651ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | |2.6% {546ms} MONode(MOGraphElement)>>isNotSelected | | | 1.7% {357ms} MONode(MOGraphElement)>>isSelected | | 1.4% {294ms} Point>>abs ==============
Cheers, Jannik _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
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
I spent some time on understand what's going on with your code. I have an answer, but no solution yet.
Clearly, MessageTally is of little help to understand why eDSM is slow. The bitmap caching is not effective in your case, which is one big reason of the slowdown. The reason is that your Mondrian view is defined as one unique node. This is not a problem, but your node is really big. A square of more than 8000 pixels. 8000 x 8000 x 32 = 2,048,000,000. A bitmap of that size weights 2Gb. Which is a bit a lot (expression used in Nice (FR) to say it is a lot). One idea, is to use the bitmap cache for inner nodes. However, probably due to my lake of knowledge of Morphic, I cannot make it work the way I want.
Two solutions: - decouple of visualization into smaller pieces. for example having a cell as a node just above the root - wait for my coming to Lille in a couple of weeks.
Side story: I found what the problem was by defining a small profiler. The screen shot shows the activity of the MOEdge class. Frequencies of received messages by instance of MOEdge are shown in the graphic. By doing a scrolling, the curve is moving, meaning that instances of MOEdge receive message. This suggested me that the cache is not operating.
Cheers, Alexandre
On 19 Jun 2010, at 08:43, Laval Jannik wrote:
On Jun 19, 2010, at 14:31 , Tudor Girba wrote:
Hi Jannik,
From this trace, it looks like the time is spent on rendering.
I understand it is still slow, but did you notice any improvement since the caching? When I tried eDSM, it looked significantly faster. I mean before I could not scroll at all, now I can even if only slowly. Could you confirm this?
My experience is not so faster: before I could scroll slowly, now I can scroll slowly. Maybe not as much as before, but the difference is not evident. I will do some experiment to see more.
Cheers, Jannik
Cheers, Doru
On 19 Jun 2010, at 14:25, Laval Jannik wrote:
Hi All,
I do a "profile all UI" and a scroll in a eDSM. The eDSM has been built on MooseModel of Moose itself and made with the 77 model packages.
I hope the result can help. Results follows:
============
Process: (40s) 211550208: nil
58.7% {12320ms} WorldState>>doOneCycleFor: 56.8% {11921ms} WorldState>>doOneCycleNowFor: |54.9% {11522ms} WorldState>>displayWorldSafely: | |54.9% {11522ms} PasteUpMorph>>displayWorld | | 54.9% {11522ms} PasteUpMorph>>privateOuterDisplayWorld | | 54.9% {11522ms} WorldState>>displayWorld:submorphs: | | 54.9% {11522ms} WorldState>>drawWorld:submorphs:invalidAreasOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} StandardWindow(Morph)>>fullDrawOn: | | 54.9% {11522ms} StandardWindow(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} ScrollPane(Morph)>>fullDrawOn: | | 54.9% {11522ms} ScrollPane(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} TransformMorph(Morph)>>fullDrawOn: | | 54.8% {11501ms} TransformMorph>>drawSubmorphsOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDraw: | | 54.8% {11501ms} MOCanvas(Morph)>>fullDrawOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>drawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>draw: | | 54.8% {11501ms} MOCanvas>>drawOn: | | 54.8% {11501ms} MORoot(MONode)>>displayOn: | | 30.9% {6485ms} MONode>>displayOn: | | |18.1% {3799ms} MOEdge>>displayOn: | | | |17.1% {3589ms} MOStraightLineShape>>display:on: | | | | 5.8% {1217ms} FormCanvas>>line:to:width:color: | | | | |2.9% {609ms} FormCanvas>>setFillColor: | | | | | |1.4% {294ms} GrafPort>>fillPattern: | | | | | | 1.2% {252ms} GrafPort(BitBlt)>>fillColor: | | | | |1.1% {231ms} GrafPort(BitBlt)>>drawFrom:to: | | | | 3.3% {693ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |3.1% {651ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 2.7% {567ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.9% {399ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.2% {252ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.5% {525ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |2.3% {483ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 1.7% {357ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.5% {315ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.1% {231ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.3% {483ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | | |1.9% {399ms} MONode(MOGraphElement)>>isNotSelected | | | | | 1.3% {273ms} MONode(MOGraphElement)>>isSelected | | | | 1.1% {231ms} Point>>abs | | |12.2% {2561ms} MONode>>displayOn: | | | 8.4% {1763ms} MOEdge>>displayOn: | | | |8.0% {1679ms} MOStraightLineShape>>display:on: | | | | 2.6% {546ms} FormCanvas>>line:to:width:color: | | | | |1.3% {273ms} FormCanvas>>setFillColor: | | | | 1.5% {315ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |1.4% {294ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 1.3% {273ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.3% {273ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |1.2% {252ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.1% {231ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | 2.9% {609ms} MONode>>displayOn: | | | 2.1% {441ms} MOEdge>>displayOn: | | | 2.0% {420ms} MOStraightLineShape>>display:on: | | 23.4% {4911ms} MOEdge>>displayOn: | | 22.0% {4617ms} MOStraightLineShape>>display:on: | | 7.5% {1574ms} FormCanvas>>line:to:width:color: | | |3.5% {735ms} FormCanvas>>setFillColor: | | | |1.7% {357ms} GrafPort>>fillPattern: | | | | 1.5% {315ms} GrafPort(BitBlt)>>fillColor: | | | | 1.2% {252ms} DisplayScreen(Form)>>bitPatternFor: | | |1.4% {294ms} GrafPort(BitBlt)>>drawFrom:to: | | 3.9% {819ms} MOStraightLineShape(MOLineShape)>>colorFor: | | |3.7% {777ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | 3.2% {672ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.4% {504ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.3% {273ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | 3.5% {735ms} MOStraightLineShape(MOLineShape)>>widthFor: | | |3.1% {651ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.3% {483ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.5% {315ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | 1.0% {210ms} IdentityDictionary>>scanFor: | | 3.1% {651ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | |2.6% {546ms} MONode(MOGraphElement)>>isNotSelected | | | 1.7% {357ms} MONode(MOGraphElement)>>isSelected | | 1.4% {294ms} Point>>abs ==============
Cheers, Jannik _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
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
Hi Alex, Thank you for your investigation :).
What I will do: - change the big node of DSM. I would to do it, and I have forgotten it. So I will do it soon. - wait for your coming to Lille: I want you show me your new profiler, which seems to be cool.
Thank you. Jannik
On Jun 22, 2010, at 00:54 , Alexandre Bergel wrote:
I spent some time on understand what's going on with your code. I have an answer, but no solution yet.
Clearly, MessageTally is of little help to understand why eDSM is slow. The bitmap caching is not effective in your case, which is one big reason of the slowdown. The reason is that your Mondrian view is defined as one unique node. This is not a problem, but your node is really big. A square of more than 8000 pixels. 8000 x 8000 x 32 = 2,048,000,000. A bitmap of that size weights 2Gb. Which is a bit a lot (expression used in Nice (FR) to say it is a lot). One idea, is to use the bitmap cache for inner nodes. However, probably due to my lake of knowledge of Morphic, I cannot make it work the way I want.
Two solutions:
- decouple of visualization into smaller pieces. for example having a cell as a node just above the root
- wait for my coming to Lille in a couple of weeks.
Side story: I found what the problem was by defining a small profiler. The screen shot shows the activity of the MOEdge class. Frequencies of received messages by instance of MOEdge are shown in the graphic. By doing a scrolling, the curve is moving, meaning that instances of MOEdge receive message. This suggested me that the cache is not operating.
Cheers, Alexandre
<Screen shot 2010-06-21 at 18.52.20.png>
On 19 Jun 2010, at 08:43, Laval Jannik wrote:
On Jun 19, 2010, at 14:31 , Tudor Girba wrote:
Hi Jannik,
From this trace, it looks like the time is spent on rendering.
I understand it is still slow, but did you notice any improvement since the caching? When I tried eDSM, it looked significantly faster. I mean before I could not scroll at all, now I can even if only slowly. Could you confirm this?
My experience is not so faster: before I could scroll slowly, now I can scroll slowly. Maybe not as much as before, but the difference is not evident. I will do some experiment to see more.
Cheers, Jannik
Cheers, Doru
On 19 Jun 2010, at 14:25, Laval Jannik wrote:
Hi All,
I do a "profile all UI" and a scroll in a eDSM. The eDSM has been built on MooseModel of Moose itself and made with the 77 model packages.
I hope the result can help. Results follows:
============
Process: (40s) 211550208: nil
58.7% {12320ms} WorldState>>doOneCycleFor: 56.8% {11921ms} WorldState>>doOneCycleNowFor: |54.9% {11522ms} WorldState>>displayWorldSafely: | |54.9% {11522ms} PasteUpMorph>>displayWorld | | 54.9% {11522ms} PasteUpMorph>>privateOuterDisplayWorld | | 54.9% {11522ms} WorldState>>displayWorld:submorphs: | | 54.9% {11522ms} WorldState>>drawWorld:submorphs:invalidAreasOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} StandardWindow(Morph)>>fullDrawOn: | | 54.9% {11522ms} StandardWindow(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} ScrollPane(Morph)>>fullDrawOn: | | 54.9% {11522ms} ScrollPane(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} TransformMorph(Morph)>>fullDrawOn: | | 54.8% {11501ms} TransformMorph>>drawSubmorphsOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDraw: | | 54.8% {11501ms} MOCanvas(Morph)>>fullDrawOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>drawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>draw: | | 54.8% {11501ms} MOCanvas>>drawOn: | | 54.8% {11501ms} MORoot(MONode)>>displayOn: | | 30.9% {6485ms} MONode>>displayOn: | | |18.1% {3799ms} MOEdge>>displayOn: | | | |17.1% {3589ms} MOStraightLineShape>>display:on: | | | | 5.8% {1217ms} FormCanvas>>line:to:width:color: | | | | |2.9% {609ms} FormCanvas>>setFillColor: | | | | | |1.4% {294ms} GrafPort>>fillPattern: | | | | | | 1.2% {252ms} GrafPort(BitBlt)>>fillColor: | | | | |1.1% {231ms} GrafPort(BitBlt)>>drawFrom:to: | | | | 3.3% {693ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |3.1% {651ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 2.7% {567ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.9% {399ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.2% {252ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.5% {525ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |2.3% {483ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 1.7% {357ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.5% {315ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.1% {231ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.3% {483ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | | |1.9% {399ms} MONode(MOGraphElement)>>isNotSelected | | | | | 1.3% {273ms} MONode(MOGraphElement)>>isSelected | | | | 1.1% {231ms} Point>>abs | | |12.2% {2561ms} MONode>>displayOn: | | | 8.4% {1763ms} MOEdge>>displayOn: | | | |8.0% {1679ms} MOStraightLineShape>>display:on: | | | | 2.6% {546ms} FormCanvas>>line:to:width:color: | | | | |1.3% {273ms} FormCanvas>>setFillColor: | | | | 1.5% {315ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |1.4% {294ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 1.3% {273ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.3% {273ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |1.2% {252ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.1% {231ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | 2.9% {609ms} MONode>>displayOn: | | | 2.1% {441ms} MOEdge>>displayOn: | | | 2.0% {420ms} MOStraightLineShape>>display:on: | | 23.4% {4911ms} MOEdge>>displayOn: | | 22.0% {4617ms} MOStraightLineShape>>display:on: | | 7.5% {1574ms} FormCanvas>>line:to:width:color: | | |3.5% {735ms} FormCanvas>>setFillColor: | | | |1.7% {357ms} GrafPort>>fillPattern: | | | | 1.5% {315ms} GrafPort(BitBlt)>>fillColor: | | | | 1.2% {252ms} DisplayScreen(Form)>>bitPatternFor: | | |1.4% {294ms} GrafPort(BitBlt)>>drawFrom:to: | | 3.9% {819ms} MOStraightLineShape(MOLineShape)>>colorFor: | | |3.7% {777ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | 3.2% {672ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.4% {504ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.3% {273ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | 3.5% {735ms} MOStraightLineShape(MOLineShape)>>widthFor: | | |3.1% {651ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.3% {483ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.5% {315ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | 1.0% {210ms} IdentityDictionary>>scanFor: | | 3.1% {651ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | |2.6% {546ms} MONode(MOGraphElement)>>isNotSelected | | | 1.7% {357ms} MONode(MOGraphElement)>>isSelected | | 1.4% {294ms} Point>>abs ==============
Cheers, Jannik _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
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
Hi Alex,
On 22 Jun 2010, at 00:54, Alexandre Bergel wrote:
I spent some time on understand what's going on with your code. I have an answer, but no solution yet.
Clearly, MessageTally is of little help to understand why eDSM is slow. The bitmap caching is not effective in your case, which is one big reason of the slowdown. The reason is that your Mondrian view is defined as one unique node. This is not a problem, but your node is really big. A square of more than 8000 pixels. 8000 x 8000 x 32 = 2,048,000,000. A bitmap of that size weights 2Gb. Which is a bit a lot (expression used in Nice (FR) to say it is a lot). One idea, is to use the bitmap cache for inner nodes. However, probably due to my lake of knowledge of Morphic, I cannot make it work the way I want.
Cool investigation, but I still do not understand what the problem is :). Does that mean that all the time is spent on drawing, or somewhere else? If it is not spent on drawing, now that we have the caching of properties, do we still need the bitmap caching?
Two solutions:
- decouple of visualization into smaller pieces. for example having
a cell as a node just above the root
- wait for my coming to Lille in a couple of weeks.
Side story: I found what the problem was by defining a small profiler. The screen shot shows the activity of the MOEdge class. Frequencies of received messages by instance of MOEdge are shown in the graphic. By doing a scrolling, the curve is moving, meaning that instances of MOEdge receive message. This suggested me that the cache is not operating.
Pretty cool :).How can we use it :)?
Cheers, Doru
Cheers, Alexandre
<Screen shot 2010-06-21 at 18.52.20.png>
On 19 Jun 2010, at 08:43, Laval Jannik wrote:
On Jun 19, 2010, at 14:31 , Tudor Girba wrote:
Hi Jannik,
From this trace, it looks like the time is spent on rendering.
I understand it is still slow, but did you notice any improvement since the caching? When I tried eDSM, it looked significantly faster. I mean before I could not scroll at all, now I can even if only slowly. Could you confirm this?
My experience is not so faster: before I could scroll slowly, now I can scroll slowly. Maybe not as much as before, but the difference is not evident. I will do some experiment to see more.
Cheers, Jannik
Cheers, Doru
On 19 Jun 2010, at 14:25, Laval Jannik wrote:
Hi All,
I do a "profile all UI" and a scroll in a eDSM. The eDSM has been built on MooseModel of Moose itself and made with the 77 model packages.
I hope the result can help. Results follows:
============
Process: (40s) 211550208: nil
58.7% {12320ms} WorldState>>doOneCycleFor: 56.8% {11921ms} WorldState>>doOneCycleNowFor: |54.9% {11522ms} WorldState>>displayWorldSafely: | |54.9% {11522ms} PasteUpMorph>>displayWorld | | 54.9% {11522ms} PasteUpMorph>>privateOuterDisplayWorld | | 54.9% {11522ms} WorldState>>displayWorld:submorphs: | | 54.9% {11522ms} WorldState>>drawWorld:submorphs:invalidAreasOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} StandardWindow(Morph)>>fullDrawOn: | | 54.9% {11522ms} StandardWindow(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} ScrollPane(Morph)>>fullDrawOn: | | 54.9% {11522ms} ScrollPane(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} TransformMorph(Morph)>>fullDrawOn: | | 54.8% {11501ms} TransformMorph>>drawSubmorphsOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDraw: | | 54.8% {11501ms} MOCanvas(Morph)>>fullDrawOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>drawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>draw: | | 54.8% {11501ms} MOCanvas>>drawOn: | | 54.8% {11501ms} MORoot(MONode)>>displayOn: | | 30.9% {6485ms} MONode>>displayOn: | | |18.1% {3799ms} MOEdge>>displayOn: | | | |17.1% {3589ms} MOStraightLineShape>>display:on: | | | | 5.8% {1217ms} FormCanvas>>line:to:width:color: | | | | |2.9% {609ms} FormCanvas>>setFillColor: | | | | | | 1.4% {294ms} GrafPort>>fillPattern: | | | | | | 1.2% {252ms} GrafPort(BitBlt)>>fillColor: | | | | |1.1% {231ms} GrafPort(BitBlt)>>drawFrom:to: | | | | 3.3% {693ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |3.1% {651ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 2.7% {567ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.9% {399ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.2% {252ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.5% {525ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |2.3% {483ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 1.7% {357ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.5% {315ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.1% {231ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.3% {483ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | | |1.9% {399ms} MONode(MOGraphElement)>>isNotSelected | | | | | 1.3% {273ms} MONode(MOGraphElement)>>isSelected | | | | 1.1% {231ms} Point>>abs | | |12.2% {2561ms} MONode>>displayOn: | | | 8.4% {1763ms} MOEdge>>displayOn: | | | |8.0% {1679ms} MOStraightLineShape>>display:on: | | | | 2.6% {546ms} FormCanvas>>line:to:width:color: | | | | | 1.3% {273ms} FormCanvas>>setFillColor: | | | | 1.5% {315ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | | 1.4% {294ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 1.3% {273ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.3% {273ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | | 1.2% {252ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.1% {231ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | 2.9% {609ms} MONode>>displayOn: | | | 2.1% {441ms} MOEdge>>displayOn: | | | 2.0% {420ms} MOStraightLineShape>>display:on: | | 23.4% {4911ms} MOEdge>>displayOn: | | 22.0% {4617ms} MOStraightLineShape>>display:on: | | 7.5% {1574ms} FormCanvas>>line:to:width:color: | | |3.5% {735ms} FormCanvas>>setFillColor: | | | |1.7% {357ms} GrafPort>>fillPattern: | | | | 1.5% {315ms} GrafPort(BitBlt)>>fillColor: | | | | 1.2% {252ms} DisplayScreen(Form)>>bitPatternFor: | | |1.4% {294ms} GrafPort(BitBlt)>>drawFrom:to: | | 3.9% {819ms} MOStraightLineShape(MOLineShape)>>colorFor: | | |3.7% {777ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | 3.2% {672ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.4% {504ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.3% {273ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | 3.5% {735ms} MOStraightLineShape(MOLineShape)>>widthFor: | | |3.1% {651ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.3% {483ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.5% {315ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | 1.0% {210ms} IdentityDictionary>>scanFor: | | 3.1% {651ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | |2.6% {546ms} MONode(MOGraphElement)>>isNotSelected | | | 1.7% {357ms} MONode(MOGraphElement)>>isSelected | | 1.4% {294ms} Point>>abs ==============
Cheers, Jannik _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
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
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
Cool investigation, but I still do not understand what the problem is :). Does that mean that all the time is spent on drawing, or somewhere else? If it is not spent on drawing, now that we have the caching of properties, do we still need the bitmap caching?
It is spent on drawing because there is no bitmap cache.
Two solutions:
- decouple of visualization into smaller pieces. for example having a cell as a node just above the root
- wait for my coming to Lille in a couple of weeks.
Side story: I found what the problem was by defining a small profiler. The screen shot shows the activity of the MOEdge class. Frequencies of received messages by instance of MOEdge are shown in the graphic. By doing a scrolling, the curve is moving, meaning that instances of MOEdge receive message. This suggested me that the cache is not operating.
Pretty cool :).How can we use it :)?
Ok, I will package it then. Just give me a few days.
Alexandre
Cheers, Alexandre
<Screen shot 2010-06-21 at 18.52.20.png>
On 19 Jun 2010, at 08:43, Laval Jannik wrote:
On Jun 19, 2010, at 14:31 , Tudor Girba wrote:
Hi Jannik,
From this trace, it looks like the time is spent on rendering.
I understand it is still slow, but did you notice any improvement since the caching? When I tried eDSM, it looked significantly faster. I mean before I could not scroll at all, now I can even if only slowly. Could you confirm this?
My experience is not so faster: before I could scroll slowly, now I can scroll slowly. Maybe not as much as before, but the difference is not evident. I will do some experiment to see more.
Cheers, Jannik
Cheers, Doru
On 19 Jun 2010, at 14:25, Laval Jannik wrote:
Hi All,
I do a "profile all UI" and a scroll in a eDSM. The eDSM has been built on MooseModel of Moose itself and made with the 77 model packages.
I hope the result can help. Results follows:
============
Process: (40s) 211550208: nil
58.7% {12320ms} WorldState>>doOneCycleFor: 56.8% {11921ms} WorldState>>doOneCycleNowFor: |54.9% {11522ms} WorldState>>displayWorldSafely: | |54.9% {11522ms} PasteUpMorph>>displayWorld | | 54.9% {11522ms} PasteUpMorph>>privateOuterDisplayWorld | | 54.9% {11522ms} WorldState>>displayWorld:submorphs: | | 54.9% {11522ms} WorldState>>drawWorld:submorphs:invalidAreasOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} StandardWindow(Morph)>>fullDrawOn: | | 54.9% {11522ms} StandardWindow(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} ScrollPane(Morph)>>fullDrawOn: | | 54.9% {11522ms} ScrollPane(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} TransformMorph(Morph)>>fullDrawOn: | | 54.8% {11501ms} TransformMorph>>drawSubmorphsOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDraw: | | 54.8% {11501ms} MOCanvas(Morph)>>fullDrawOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>drawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>draw: | | 54.8% {11501ms} MOCanvas>>drawOn: | | 54.8% {11501ms} MORoot(MONode)>>displayOn: | | 30.9% {6485ms} MONode>>displayOn: | | |18.1% {3799ms} MOEdge>>displayOn: | | | |17.1% {3589ms} MOStraightLineShape>>display:on: | | | | 5.8% {1217ms} FormCanvas>>line:to:width:color: | | | | |2.9% {609ms} FormCanvas>>setFillColor: | | | | | |1.4% {294ms} GrafPort>>fillPattern: | | | | | | 1.2% {252ms} GrafPort(BitBlt)>>fillColor: | | | | |1.1% {231ms} GrafPort(BitBlt)>>drawFrom:to: | | | | 3.3% {693ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |3.1% {651ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 2.7% {567ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.9% {399ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.2% {252ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.5% {525ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |2.3% {483ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 1.7% {357ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.5% {315ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.1% {231ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.3% {483ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | | |1.9% {399ms} MONode(MOGraphElement)>>isNotSelected | | | | | 1.3% {273ms} MONode(MOGraphElement)>>isSelected | | | | 1.1% {231ms} Point>>abs | | |12.2% {2561ms} MONode>>displayOn: | | | 8.4% {1763ms} MOEdge>>displayOn: | | | |8.0% {1679ms} MOStraightLineShape>>display:on: | | | | 2.6% {546ms} FormCanvas>>line:to:width:color: | | | | |1.3% {273ms} FormCanvas>>setFillColor: | | | | 1.5% {315ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |1.4% {294ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 1.3% {273ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.3% {273ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |1.2% {252ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.1% {231ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | 2.9% {609ms} MONode>>displayOn: | | | 2.1% {441ms} MOEdge>>displayOn: | | | 2.0% {420ms} MOStraightLineShape>>display:on: | | 23.4% {4911ms} MOEdge>>displayOn: | | 22.0% {4617ms} MOStraightLineShape>>display:on: | | 7.5% {1574ms} FormCanvas>>line:to:width:color: | | |3.5% {735ms} FormCanvas>>setFillColor: | | | |1.7% {357ms} GrafPort>>fillPattern: | | | | 1.5% {315ms} GrafPort(BitBlt)>>fillColor: | | | | 1.2% {252ms} DisplayScreen(Form)>>bitPatternFor: | | |1.4% {294ms} GrafPort(BitBlt)>>drawFrom:to: | | 3.9% {819ms} MOStraightLineShape(MOLineShape)>>colorFor: | | |3.7% {777ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | 3.2% {672ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.4% {504ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.3% {273ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | 3.5% {735ms} MOStraightLineShape(MOLineShape)>>widthFor: | | |3.1% {651ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.3% {483ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.5% {315ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | 1.0% {210ms} IdentityDictionary>>scanFor: | | 3.1% {651ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | |2.6% {546ms} MONode(MOGraphElement)>>isNotSelected | | | 1.7% {357ms} MONode(MOGraphElement)>>isSelected | | 1.4% {294ms} Point>>abs ==============
Cheers, Jannik _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
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
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Thank you Alex,
I modify the script, Now it is really faster. I can scroll my eDSM (with 70 packages) without slowdown. PS: I use also Cog VM :)
Cheers, Jannik
On Jun 22, 2010, at 00:54 , Alexandre Bergel wrote:
I spent some time on understand what's going on with your code. I have an answer, but no solution yet.
Clearly, MessageTally is of little help to understand why eDSM is slow. The bitmap caching is not effective in your case, which is one big reason of the slowdown. The reason is that your Mondrian view is defined as one unique node. This is not a problem, but your node is really big. A square of more than 8000 pixels. 8000 x 8000 x 32 = 2,048,000,000. A bitmap of that size weights 2Gb. Which is a bit a lot (expression used in Nice (FR) to say it is a lot). One idea, is to use the bitmap cache for inner nodes. However, probably due to my lake of knowledge of Morphic, I cannot make it work the way I want.
Two solutions:
- decouple of visualization into smaller pieces. for example having a cell as a node just above the root
- wait for my coming to Lille in a couple of weeks.
Side story: I found what the problem was by defining a small profiler. The screen shot shows the activity of the MOEdge class. Frequencies of received messages by instance of MOEdge are shown in the graphic. By doing a scrolling, the curve is moving, meaning that instances of MOEdge receive message. This suggested me that the cache is not operating.
Cheers, Alexandre
<Screen shot 2010-06-21 at 18.52.20.png>
On 19 Jun 2010, at 08:43, Laval Jannik wrote:
On Jun 19, 2010, at 14:31 , Tudor Girba wrote:
Hi Jannik,
From this trace, it looks like the time is spent on rendering.
I understand it is still slow, but did you notice any improvement since the caching? When I tried eDSM, it looked significantly faster. I mean before I could not scroll at all, now I can even if only slowly. Could you confirm this?
My experience is not so faster: before I could scroll slowly, now I can scroll slowly. Maybe not as much as before, but the difference is not evident. I will do some experiment to see more.
Cheers, Jannik
Cheers, Doru
On 19 Jun 2010, at 14:25, Laval Jannik wrote:
Hi All,
I do a "profile all UI" and a scroll in a eDSM. The eDSM has been built on MooseModel of Moose itself and made with the 77 model packages.
I hope the result can help. Results follows:
============
Process: (40s) 211550208: nil
58.7% {12320ms} WorldState>>doOneCycleFor: 56.8% {11921ms} WorldState>>doOneCycleNowFor: |54.9% {11522ms} WorldState>>displayWorldSafely: | |54.9% {11522ms} PasteUpMorph>>displayWorld | | 54.9% {11522ms} PasteUpMorph>>privateOuterDisplayWorld | | 54.9% {11522ms} WorldState>>displayWorld:submorphs: | | 54.9% {11522ms} WorldState>>drawWorld:submorphs:invalidAreasOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} StandardWindow(Morph)>>fullDrawOn: | | 54.9% {11522ms} StandardWindow(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} ScrollPane(Morph)>>fullDrawOn: | | 54.9% {11522ms} ScrollPane(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} TransformMorph(Morph)>>fullDrawOn: | | 54.8% {11501ms} TransformMorph>>drawSubmorphsOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDraw: | | 54.8% {11501ms} MOCanvas(Morph)>>fullDrawOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>drawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>draw: | | 54.8% {11501ms} MOCanvas>>drawOn: | | 54.8% {11501ms} MORoot(MONode)>>displayOn: | | 30.9% {6485ms} MONode>>displayOn: | | |18.1% {3799ms} MOEdge>>displayOn: | | | |17.1% {3589ms} MOStraightLineShape>>display:on: | | | | 5.8% {1217ms} FormCanvas>>line:to:width:color: | | | | |2.9% {609ms} FormCanvas>>setFillColor: | | | | | |1.4% {294ms} GrafPort>>fillPattern: | | | | | | 1.2% {252ms} GrafPort(BitBlt)>>fillColor: | | | | |1.1% {231ms} GrafPort(BitBlt)>>drawFrom:to: | | | | 3.3% {693ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |3.1% {651ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 2.7% {567ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.9% {399ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.2% {252ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.5% {525ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |2.3% {483ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 1.7% {357ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.5% {315ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.1% {231ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.3% {483ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | | |1.9% {399ms} MONode(MOGraphElement)>>isNotSelected | | | | | 1.3% {273ms} MONode(MOGraphElement)>>isSelected | | | | 1.1% {231ms} Point>>abs | | |12.2% {2561ms} MONode>>displayOn: | | | 8.4% {1763ms} MOEdge>>displayOn: | | | |8.0% {1679ms} MOStraightLineShape>>display:on: | | | | 2.6% {546ms} FormCanvas>>line:to:width:color: | | | | |1.3% {273ms} FormCanvas>>setFillColor: | | | | 1.5% {315ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |1.4% {294ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 1.3% {273ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.3% {273ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |1.2% {252ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.1% {231ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | 2.9% {609ms} MONode>>displayOn: | | | 2.1% {441ms} MOEdge>>displayOn: | | | 2.0% {420ms} MOStraightLineShape>>display:on: | | 23.4% {4911ms} MOEdge>>displayOn: | | 22.0% {4617ms} MOStraightLineShape>>display:on: | | 7.5% {1574ms} FormCanvas>>line:to:width:color: | | |3.5% {735ms} FormCanvas>>setFillColor: | | | |1.7% {357ms} GrafPort>>fillPattern: | | | | 1.5% {315ms} GrafPort(BitBlt)>>fillColor: | | | | 1.2% {252ms} DisplayScreen(Form)>>bitPatternFor: | | |1.4% {294ms} GrafPort(BitBlt)>>drawFrom:to: | | 3.9% {819ms} MOStraightLineShape(MOLineShape)>>colorFor: | | |3.7% {777ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | 3.2% {672ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.4% {504ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.3% {273ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | 3.5% {735ms} MOStraightLineShape(MOLineShape)>>widthFor: | | |3.1% {651ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.3% {483ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.5% {315ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | 1.0% {210ms} IdentityDictionary>>scanFor: | | 3.1% {651ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | |2.6% {546ms} MONode(MOGraphElement)>>isNotSelected | | | 1.7% {357ms} MONode(MOGraphElement)>>isSelected | | 1.4% {294ms} Point>>abs ==============
Cheers, Jannik _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
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
Cool!!!!
Alexandre
On 22 Jun 2010, at 05:30, Laval Jannik wrote:
Thank you Alex,
I modify the script, Now it is really faster. I can scroll my eDSM (with 70 packages) without slowdown. PS: I use also Cog VM :)
Cheers, Jannik
On Jun 22, 2010, at 00:54 , Alexandre Bergel wrote:
I spent some time on understand what's going on with your code. I have an answer, but no solution yet.
Clearly, MessageTally is of little help to understand why eDSM is slow. The bitmap caching is not effective in your case, which is one big reason of the slowdown. The reason is that your Mondrian view is defined as one unique node. This is not a problem, but your node is really big. A square of more than 8000 pixels. 8000 x 8000 x 32 = 2,048,000,000. A bitmap of that size weights 2Gb. Which is a bit a lot (expression used in Nice (FR) to say it is a lot). One idea, is to use the bitmap cache for inner nodes. However, probably due to my lake of knowledge of Morphic, I cannot make it work the way I want.
Two solutions:
- decouple of visualization into smaller pieces. for example having a cell as a node just above the root
- wait for my coming to Lille in a couple of weeks.
Side story: I found what the problem was by defining a small profiler. The screen shot shows the activity of the MOEdge class. Frequencies of received messages by instance of MOEdge are shown in the graphic. By doing a scrolling, the curve is moving, meaning that instances of MOEdge receive message. This suggested me that the cache is not operating.
Cheers, Alexandre
<Screen shot 2010-06-21 at 18.52.20.png>
On 19 Jun 2010, at 08:43, Laval Jannik wrote:
On Jun 19, 2010, at 14:31 , Tudor Girba wrote:
Hi Jannik,
From this trace, it looks like the time is spent on rendering.
I understand it is still slow, but did you notice any improvement since the caching? When I tried eDSM, it looked significantly faster. I mean before I could not scroll at all, now I can even if only slowly. Could you confirm this?
My experience is not so faster: before I could scroll slowly, now I can scroll slowly. Maybe not as much as before, but the difference is not evident. I will do some experiment to see more.
Cheers, Jannik
Cheers, Doru
On 19 Jun 2010, at 14:25, Laval Jannik wrote:
Hi All,
I do a "profile all UI" and a scroll in a eDSM. The eDSM has been built on MooseModel of Moose itself and made with the 77 model packages.
I hope the result can help. Results follows:
============
Process: (40s) 211550208: nil
58.7% {12320ms} WorldState>>doOneCycleFor: 56.8% {11921ms} WorldState>>doOneCycleNowFor: |54.9% {11522ms} WorldState>>displayWorldSafely: | |54.9% {11522ms} PasteUpMorph>>displayWorld | | 54.9% {11522ms} PasteUpMorph>>privateOuterDisplayWorld | | 54.9% {11522ms} WorldState>>displayWorld:submorphs: | | 54.9% {11522ms} WorldState>>drawWorld:submorphs:invalidAreasOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} StandardWindow(Morph)>>fullDrawOn: | | 54.9% {11522ms} StandardWindow(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} ScrollPane(Morph)>>fullDrawOn: | | 54.9% {11522ms} ScrollPane(Morph)>>drawSubmorphsOn: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.9% {11522ms} FormCanvas(Canvas)>>fullDraw: | | 54.9% {11522ms} TransformMorph(Morph)>>fullDrawOn: | | 54.8% {11501ms} TransformMorph>>drawSubmorphsOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDrawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>fullDraw: | | 54.8% {11501ms} MOCanvas(Morph)>>fullDrawOn: | | 54.8% {11501ms} FormCanvas(Canvas)>>drawMorph: | | 54.8% {11501ms} FormCanvas(Canvas)>>draw: | | 54.8% {11501ms} MOCanvas>>drawOn: | | 54.8% {11501ms} MORoot(MONode)>>displayOn: | | 30.9% {6485ms} MONode>>displayOn: | | |18.1% {3799ms} MOEdge>>displayOn: | | | |17.1% {3589ms} MOStraightLineShape>>display:on: | | | | 5.8% {1217ms} FormCanvas>>line:to:width:color: | | | | |2.9% {609ms} FormCanvas>>setFillColor: | | | | | |1.4% {294ms} GrafPort>>fillPattern: | | | | | | 1.2% {252ms} GrafPort(BitBlt)>>fillColor: | | | | |1.1% {231ms} GrafPort(BitBlt)>>drawFrom:to: | | | | 3.3% {693ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |3.1% {651ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 2.7% {567ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.9% {399ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.2% {252ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.5% {525ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |2.3% {483ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | | 1.7% {357ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | | | 1.5% {315ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | | | 1.1% {231ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | | 2.3% {483ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | | |1.9% {399ms} MONode(MOGraphElement)>>isNotSelected | | | | | 1.3% {273ms} MONode(MOGraphElement)>>isSelected | | | | 1.1% {231ms} Point>>abs | | |12.2% {2561ms} MONode>>displayOn: | | | 8.4% {1763ms} MOEdge>>displayOn: | | | |8.0% {1679ms} MOStraightLineShape>>display:on: | | | | 2.6% {546ms} FormCanvas>>line:to:width:color: | | | | |1.3% {273ms} FormCanvas>>setFillColor: | | | | 1.5% {315ms} MOStraightLineShape(MOLineShape)>>colorFor: | | | | |1.4% {294ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | | | 1.3% {273ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.3% {273ms} MOStraightLineShape(MOLineShape)>>widthFor: | | | | |1.2% {252ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | | 1.1% {231ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | | 2.9% {609ms} MONode>>displayOn: | | | 2.1% {441ms} MOEdge>>displayOn: | | | 2.0% {420ms} MOStraightLineShape>>display:on: | | 23.4% {4911ms} MOEdge>>displayOn: | | 22.0% {4617ms} MOStraightLineShape>>display:on: | | 7.5% {1574ms} FormCanvas>>line:to:width:color: | | |3.5% {735ms} FormCanvas>>setFillColor: | | | |1.7% {357ms} GrafPort>>fillPattern: | | | | 1.5% {315ms} GrafPort(BitBlt)>>fillColor: | | | | 1.2% {252ms} DisplayScreen(Form)>>bitPatternFor: | | |1.4% {294ms} GrafPort(BitBlt)>>drawFrom:to: | | 3.9% {819ms} MOStraightLineShape(MOLineShape)>>colorFor: | | |3.7% {777ms} MOEdge(MOGraphElement)>>cachedNamed:ifAbsentInitializeWith: | | | 3.2% {672ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.4% {504ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.3% {273ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | 3.5% {735ms} MOStraightLineShape(MOLineShape)>>widthFor: | | |3.1% {651ms} MOEdge(MOGraphElement)>>attributeAt:ifAbsent: | | | 2.3% {483ms} IdentityDictionary(Dictionary)>>at:ifAbsentPut: | | | 2.1% {441ms} IdentityDictionary(Dictionary)>>at:ifAbsent: | | | 1.5% {315ms} IdentityDictionary(HashedCollection)>>findElementOrNil: | | | 1.0% {210ms} IdentityDictionary>>scanFor: | | 3.1% {651ms} MOStraightLineShape(MOLineShape)>>getAttachPointsFor: | | |2.6% {546ms} MONode(MOGraphElement)>>isNotSelected | | | 1.7% {357ms} MONode(MOGraphElement)>>isSelected | | 1.4% {294ms} Point>>abs ==============
Cheers, Jannik _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
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
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
Hi,
Can't test? where is MOLabelShape, why was it deleted?? I use it and now is gone!!! I even had a specialization of it for Torch...
Veronica
On 17 Jun 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
Hi Veronica,
As far as I know, the complete functionality of MOLabelShape is in MORectangleShape. I guess that is why Alex removed it. I do not particularly like that, but this is the situation now.
Could you subclass that one for the time being? Also, is the extension not of interest for the general public? If yes, maybe it would make sense to publish it in Mondrian directly :).
Cheers, Doru
On 18 Jun 2010, at 09:43, Veronica Isabel Uquillas Gomez wrote:
Hi,
Can't test? where is MOLabelShape, why was it deleted?? I use it and now is gone!!! I even had a specialization of it for Torch...
Veronica
On 17 Jun 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
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."
Hi Doru,
In fact MOLabelShape shares the attributes with MOBoundedShape (rectangle does not do anything), but the drawing is not the same.
see the images, even having color black the text with the current version is like grey. That was one of the reasons for using labelShape and not rectangle at the beginning. Plus the vertical padding works different, by default is 0 and you can not see the character p clearly, if I add a verticalPadding = 1 then i have more space that the one i need (see third image).
LabelShape controls that better with interlineSpace (not an accessor)... My extension changed that internal value, and i have an extra control for fonts.. In addition, Mondrian uses font cache (correct), but if you change the system fonts, that was not reflected on mondrian... I needed to validate that for Torch, another reason for my specialization...
If i make it publish, i will add in it the drawing behavior that was just removed.
regards, Veronica
vs
On 18 Jun 2010, at 11:48, Tudor Girba wrote:
Hi Veronica,
As far as I know, the complete functionality of MOLabelShape is in MORectangleShape. I guess that is why Alex removed it. I do not particularly like that, but this is the situation now.
Could you subclass that one for the time being? Also, is the extension not of interest for the general public? If yes, maybe it would make sense to publish it in Mondrian directly :).
Cheers, Doru
On 18 Jun 2010, at 09:43, Veronica Isabel Uquillas Gomez wrote:
Hi,
Can't test? where is MOLabelShape, why was it deleted?? I use it and now is gone!!! I even had a specialization of it for Torch...
Veronica
On 17 Jun 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
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
In fact MOLabelShape shares the attributes with MOBoundedShape (rectangle does not do anything), but the drawing is not the same.
MORectangleShape does not do anything. Some of the functionalities of MOBoundedShape will be moved down to MORectangleShape. Also, MOBoundedShape may be merged with MOFilledShape. I have to think about that. So far, it does not make sense to have MONodeShape MOFilledShape MOBoundedShape MOCurveShape MODiamondShape ... MORectangleShape
see the images, even having color black the text with the current version is like grey. That was one of the reasons for using labelShape and not rectangle at the beginning.
I cannot reproduce this difference of color. I attached what I have in my image. The code that displays the string is rigorously the same.
I tried this:
with MOLabelShape, the font is darker than with MORectangleShape.
I found the reason. MORectangleShape always displays a whiteBackground before displaying the text. For some reason, the text appears gray in that situation. I added MOBoundedShape>>withoutBackGroup. It solves the problem apparently.
Does this solve your problem?
Plus the vertical padding works different, by default is 0 and you can not see the character p clearly, if I add a verticalPadding = 1 then i have more space that the one i need (see third image).
I cannot reproduce this. I inserted some times ago textPadding.
Does it solve your issue?
LabelShape controls that better with interlineSpace (not an accessor)... My extension changed that internal value, and i have an extra control for fonts..
Which control?
In addition, Mondrian uses font cache (correct), but if you change the system fonts, that was not reflected on mondrian... I needed to validate that for Torch, another reason for my specialization...
I guess it should.
If i make it publish, i will add in it the drawing behavior that was just removed.
I do not understand. Please, let me know how after this discussion if you are happy with MORectangleShape.
Cheers, Alexandre
regards, Veronica
<labelShape-extension.png> vs<labelShape-now.png>
<labelShape-now+padding.png>
On 18 Jun 2010, at 11:48, Tudor Girba wrote:
Hi Veronica,
As far as I know, the complete functionality of MOLabelShape is in MORectangleShape. I guess that is why Alex removed it. I do not particularly like that, but this is the situation now.
Could you subclass that one for the time being? Also, is the extension not of interest for the general public? If yes, maybe it would make sense to publish it in Mondrian directly :).
Cheers, Doru
On 18 Jun 2010, at 09:43, Veronica Isabel Uquillas Gomez wrote:
Hi,
Can't test? where is MOLabelShape, why was it deleted?? I use it and now is gone!!! I even had a specialization of it for Torch...
Veronica
On 17 Jun 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
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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 18 Jun 2010, at 15:44, Alexandre Bergel wrote:
In fact MOLabelShape shares the attributes with MOBoundedShape (rectangle does not do anything), but the drawing is not the same.
MORectangleShape does not do anything. Some of the functionalities of MOBoundedShape will be moved down to MORectangleShape. Also, MOBoundedShape may be merged with MOFilledShape. I have to think about that. So far, it does not make sense to have MONodeShape MOFilledShape MOBoundedShape MOCurveShape MODiamondShape ... MORectangleShape
see the images, even having color black the text with the current version is like grey. That was one of the reasons for using labelShape and not rectangle at the beginning.
I cannot reproduce this difference of color. I attached what I have in my image. The code that displays the string is rigorously the same. <Screen shot 2010-06-18 at 09.09.04.png><Screen shot 2010-06-18 at 09.12.36.png>
I tried this:
<Screen shot 2010-06-18 at 09.25.44.png>
with MOLabelShape, the font is darker than with MORectangleShape.
I found the reason. MORectangleShape always displays a whiteBackground before displaying the text. For some reason, the text appears gray in that situation. I added MOBoundedShape>>withoutBackGroup. It solves the problem apparently. <Screen shot 2010-06-18 at 09.32.35.png>
Does this solve your problem?
Plus the vertical padding works different, by default is 0 and you can not see the character p clearly, if I add a verticalPadding = 1 then i have more space that the one i need (see third image).
I cannot reproduce this. I inserted some times ago textPadding.
this is hard to reproduce with single nodes only with nested nodes.... but the difference is basically in the computation of textHeightFor:
<Screen shot 2010-06-18 at 09.27.48.png>
Does it solve your issue?
LabelShape controls that better with interlineSpace (not an accessor)... My extension changed that internal value, and i have an extra control for fonts..
Which control?
I calculate the width a label uses before the drawing is done, for setting the width to other nodes
In addition, Mondrian uses font cache (correct), but if you change the system fonts, that was not reflected on mondrian... I needed to validate that for Torch, another reason for my specialization...
I guess it should.
MCBoundedShape manages this ok (labelShape was failing in that)
If i make it publish, i will add in it the drawing behavior that was just removed.
I do not understand.
I meant the drawing method of MCLabelShape
Please, let me know how after this discussion if you are happy with MORectangleShape.
I will try with your last version, but will still keep my extension for the two first reasons...
Cheers, Alexandre
regards, Veronica
<labelShape-extension.png> vs<labelShape-now.png>
<labelShape-now+padding.png>
On 18 Jun 2010, at 11:48, Tudor Girba wrote:
Hi Veronica,
As far as I know, the complete functionality of MOLabelShape is in MORectangleShape. I guess that is why Alex removed it. I do not particularly like that, but this is the situation now.
Could you subclass that one for the time being? Also, is the extension not of interest for the general public? If yes, maybe it would make sense to publish it in Mondrian directly :).
Cheers, Doru
On 18 Jun 2010, at 09:43, Veronica Isabel Uquillas Gomez wrote:
Hi,
Can't test? where is MOLabelShape, why was it deleted?? I use it and now is gone!!! I even had a specialization of it for Torch...
Veronica
On 17 Jun 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
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
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
As far as I know, the complete functionality of MOLabelShape is in MORectangleShape. I guess that is why Alex removed it. I do not particularly like that, but this is the situation now.
Indeed. There is a severe duplication of functionalities in MORectangleShape and MOLabelShape. Sorry Veronica to add you more work.
Could you subclass that one for the time being? Also, is the extension not of interest for the general public? If yes, maybe it would make sense to publish it in Mondrian directly :).
Good question.
Alexandre
Cheers, Doru
On 18 Jun 2010, at 09:43, Veronica Isabel Uquillas Gomez wrote:
Hi,
Can't test? where is MOLabelShape, why was it deleted?? I use it and now is gone!!! I even had a specialization of it for Torch...
Veronica
On 17 Jun 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
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
On 18 Jun 2010, at 14:53, Alexandre Bergel wrote:
As far as I know, the complete functionality of MOLabelShape is in MORectangleShape. I guess that is why Alex removed it. I do not particularly like that, but this is the situation now.
Indeed. There is a severe duplication of functionalities in MORectangleShape and MOLabelShape. Sorry Veronica to add you more work.
i agree with removing duplications, but removing a class that may be used for other applications without notifying, no... the version in which it was deleted has not even a comment for that...
Could you subclass that one for the time being? Also, is the extension not of interest for the general public? If yes, maybe it would make sense to publish it in Mondrian directly :).
Good question.
Alexandre
Cheers, Doru
On 18 Jun 2010, at 09:43, Veronica Isabel Uquillas Gomez wrote:
Hi,
Can't test? where is MOLabelShape, why was it deleted?? I use it and now is gone!!! I even had a specialization of it for Torch...
Veronica
On 17 Jun 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
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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
As far as I know, the complete functionality of MOLabelShape is in MORectangleShape. I guess that is why Alex removed it. I do not particularly like that, but this is the situation now.
Indeed. There is a severe duplication of functionalities in MORectangleShape and MOLabelShape. Sorry Veronica to add you more work.
i agree with removing duplications, but removing a class that may be used for other applications without notifying, no... the version in which it was deleted has not even a comment for that...
Sorry about that. But this kind of situation happens in every multi-developper session, especially in which no money is involved. I would like to be a bit more constructive on this.
Alexandre
Could you subclass that one for the time being? Also, is the extension not of interest for the general public? If yes, maybe it would make sense to publish it in Mondrian directly :).
Good question.
Alexandre
Cheers, Doru
On 18 Jun 2010, at 09:43, Veronica Isabel Uquillas Gomez wrote:
Hi,
Can't test? where is MOLabelShape, why was it deleted?? I use it and now is gone!!! I even had a specialization of it for Torch...
Veronica
On 17 Jun 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
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
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
Yes, I removed it. Veronica, I can reintroduce it, but could you try to adapt your code with MORectangleShape ? MORectangleShape new withoutBorder; text: [:v | ... ] closely emulates MOLabelShape.
Let me know if this is a problem.
Cheers, Alexandre
On 18 Jun 2010, at 03:43, Veronica Isabel Uquillas Gomez wrote:
Hi,
Can't test? where is MOLabelShape, why was it deleted?? I use it and now is gone!!! I even had a specialization of it for Torch...
Veronica
On 17 Jun 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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I did, and i also sent a mail explaining the differences with images...
On 18 Jun 2010, at 14:51, Alexandre Bergel wrote:
Yes, I removed it. Veronica, I can reintroduce it, but could you try to adapt your code with MORectangleShape ? MORectangleShape new withoutBorder; text: [:v | ... ] closely emulates MOLabelShape.
Let me know if this is a problem.
Cheers, Alexandre
On 18 Jun 2010, at 03:43, Veronica Isabel Uquillas Gomez wrote:
Hi,
Can't test? where is MOLabelShape, why was it deleted?? I use it and now is gone!!! I even had a specialization of it for Torch...
Veronica
On 17 Jun 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
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
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.
I instead introduced #cachedNamed:ifAbsentInitializeWith: Not all attributes must be cached (e.g., I am doing some animation on the side)
For archive, I used this expression to check whether I missed some *For: methods. -=-=-=-=-=-=-=-=-=-=-=-= (((PackageInfo named: 'Mondrian') methods select: [:mr | mr selector asString endsWith: 'For:']) collect: [:mr | mr compiledMethod]) select: [:cm | (cm sendsSelector: #cachedNamed:ifAbsentInitializeWith:) not] -=-=-=-=-=-=-=-=-=-=-=-=
I optimized what I could. I am not sure what to do with MOFormsShape although.
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?
Consider:
view node: 1 forIt: [view node: 2]].
Without the bitmap cache, you display two nodes (e.g., MOBoundedShape>>drawOn: is invoked twice). It is called just once with the bitmap cache.
Alexandre
====== |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."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Johan Fabry -
Laval Jannik -
Stéphane Ducasse -
Tudor Girba -
Veronica Isabel Uquillas Gomez