16 Jun
2010
16 Jun
'10
10:22 a.m.
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
16 Jun
16 Jun
10:59 a.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"When people care, great things can happen."
17 Jun
17 Jun
3:41 p.m.
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
4:30 p.m.
Hi Alex,
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 know, but if you compute it once why do you still need to re-render?
Cheers,
Doru
--
www.tudorgirba.com
"Some battles are better lost than fought."
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:47 p.m.
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,
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 know, but if you compute it once why do you still need to re-render?
Cheers,
Doru
--
www.tudorgirba.com
"Some battles are better lost than fought."
--
www.tudorgirba.com
"Some battles are better lost than fought."
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:33 p.m.
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. >
======
> |view o |
> view := MOViewRenderer new.
> o := OrderedCollection new: 100.
> 1 to: 100 do:[:i | o add: i].
> (view shape: (MORectangleShape new
> width: [:e | 200];
> height: 200;
> withBorder;
> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
> view nodes: o.
> view layout: (MOGridLayout new gapSize: 1).
> view open
> ======
A better version could be
-=-=-=-=-=-=-=-=-=-=-=-=
|view o a |
a := {0}.
view := MOViewRenderer new.
o := OrderedCollection new: 100.
1 to: 100 do:[:i | o add: i].
(view shape: (MORectangleShape new
width: [:e | 200];
height: 200;
withBorder;
borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
view nodes: o.
view layout: (MOGridLayout new gapSize: 1).
view open.
a
-=-=-=-=-=-=-=-=-=-=-=-=
Just inspect the expression, and see if the array a changes over the time.
Is there any remaining problem left in Mondrian related to the speed issue?
Cheers,
Alexandre
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:34 p.m.
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,
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 know, but if you compute it once why do you still need to re-render?
Cheers,
Doru
--
www.tudorgirba.com
"Some battles are better lost than fought."
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
8:50 p.m.
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:
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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
18 Jun
18 Jun
7:19 a.m.
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:
---
Jannik Laval
Hi Alex,
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 know, but if you compute it once why do you still need to re-render?
Cheers,
Doru
--
www.tudorgirba.com
"Some battles are better lost than fought."
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
9:43 a.m.
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,
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 know, but if you compute it once why do you still need to re-render?
Cheers,
Doru
--
www.tudorgirba.com
"Some battles are better lost than fought."
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:48 a.m.
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:
--
www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting
is the right one."
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Alex,
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev > Indeed, this caching should happen for all
properties and for
> all shapes (both for nodes and for edges). I think that Alex
> stopped in the middle because he did not know whether this
> caching had an effect or not.
I was wondering whether it would make sense to do this for all
the metrics. Apparently yes, I then continued. All shape
parameters should be cached.
> Alex, could you take a look at that?
Done. Mondrian-Alexandre_Bergel.470
Great. I checked a bit the implementation, and I would only
suggest to check for isCached in the attributeAt:ifAbsent: method,
instead of in every *For: methods.
> The next question is that if the border color
is called all the
> time, what is the use of the bitmap cache?
The bitmap is for not having to display inner nodes. Recursion
takes times.
I know, but if you compute it once why do you still need to re-
render?
Cheers,
Doru
>> ======
>> |view o |
>> view := MOViewRenderer new.
>> o := OrderedCollection new: 100.
>> 1 to: 100 do:[:i | o add: i].
>> (view shape: (MORectangleShape new
>> width: [:e | 200];
>> height: 200;
>> withBorder;
>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color
>> gray])).
>> view nodes: o.
>> view layout: (MOGridLayout new gapSize: 1).
>> view open
>> ======
A better version could be
-=-=-=-=-=-=-=-=-=-=-=-=
|view o a |
a := {0}.
view := MOViewRenderer new.
o := OrderedCollection new: 100.
1 to: 100 do:[:i | o add: i].
(view shape: (MORectangleShape new
width: [:e | 200];
height: 200;
withBorder;
borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
view nodes: o.
view layout: (MOGridLayout new gapSize: 1).
view open.
a
-=-=-=-=-=-=-=-=-=-=-=-=
Just inspect the expression, and see if the array a changes over
the time.
Is there any remaining problem left in Mondrian related to the
speed issue?
Cheers,
Alexandre
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
11:53 a.m.
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:
--
www.tudorgirba.com
"It's not how it is, it is how we see it."
I tested on a regular DSM with 259 namespaces and
I can now
properly scroll once it gets displayed.
Jannik, Veronica, could you check in your cases?
Cheers,
Doru
On 17 Jun 2010, at 16:30, Tudor Girba wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Alex,
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev > Indeed, this caching should happen for all
properties and for
> all shapes (both for nodes and for edges). I think that Alex
> stopped in the middle because he did not know whether this
> caching had an effect or not.
I was wondering whether it would make sense to do this for all
the metrics. Apparently yes, I then continued. All shape
parameters should be cached.
> Alex, could you take a look at that?
Done. Mondrian-Alexandre_Bergel.470
Great. I checked a bit the implementation, and I would only
suggest to check for isCached in the attributeAt:ifAbsent: method,
instead of in every *For: methods.
> The next question is that if the border color
is called all the
> time, what is the use of the bitmap cache?
The bitmap is for not having to display inner nodes. Recursion
takes times.
I know, but if you compute it once why do you still need to re-
render?
Cheers,
Doru
>> ======
>> |view o |
>> view := MOViewRenderer new.
>> o := OrderedCollection new: 100.
>> 1 to: 100 do:[:i | o add: i].
>> (view shape: (MORectangleShape new
>> width: [:e | 200];
>> height: 200;
>> withBorder;
>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color
>> gray])).
>> view nodes: o.
>> view layout: (MOGridLayout new gapSize: 1).
>> view open
>> ======
A better version could be
-=-=-=-=-=-=-=-=-=-=-=-=
|view o a |
a := {0}.
view := MOViewRenderer new.
o := OrderedCollection new: 100.
1 to: 100 do:[:i | o add: i].
(view shape: (MORectangleShape new
width: [:e | 200];
height: 200;
withBorder;
borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
view nodes: o.
view layout: (MOGridLayout new gapSize: 1).
view open.
a
-=-=-=-=-=-=-=-=-=-=-=-=
Just inspect the expression, and see if the array a changes over
the time.
Is there any remaining problem left in Mondrian related to the
speed issue?
Cheers,
Alexandre
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
1:25 p.m.
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:
--
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I tested on a regular DSM with 259 namespaces and
I can now properly scroll once it gets displayed.
Jannik, Veronica, could you check in your cases?
Cheers,
Doru
On 17 Jun 2010, at 16:30, Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Alex,
>> Indeed, this caching should happen for all properties and for all shapes (both
for nodes and for edges). I think that Alex stopped in the middle because he did not know
whether this caching had an effect or not.
>
> I was wondering whether it would make sense to do this for all the metrics.
Apparently yes, I then continued. All shape parameters should be cached.
>> Alex, could you take a look at that?
>
> Done. Mondrian-Alexandre_Bergel.470
Great. I checked a bit the implementation, and I would only suggest to check for isCached
in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>> The next question is that if the border color is called all the time, what is the
use of the bitmap cache?
>
> The bitmap is for not having to display inner nodes. Recursion takes times.
I know, but if you compute it once why do you still need to re-render?
Cheers,
Doru
>>> ======
>>> |view o |
>>> view := MOViewRenderer new.
>>> o := OrderedCollection new: 100.
>>> 1 to: 100 do:[:i | o add: i].
>>> (view shape: (MORectangleShape new
>>> width: [:e | 200];
>>> height: 200;
>>> withBorder;
>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>> view nodes: o.
>>> view layout: (MOGridLayout new gapSize: 1).
>>> view open
>>> ======
>
> A better version could be
> -=-=-=-=-=-=-=-=-=-=-=-=
> |view o a |
> a := {0}.
> view := MOViewRenderer new.
> o := OrderedCollection new: 100.
> 1 to: 100 do:[:i | o add: i].
> (view shape: (MORectangleShape new
> width: [:e | 200];
> height: 200;
> withBorder;
> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
> view nodes: o.
> view layout: (MOGridLayout new gapSize: 1).
> view open.
> a
> -=-=-=-=-=-=-=-=-=-=-=-=
>
> Just inspect the expression, and see if the array a changes over the time.
>
> Is there any remaining problem left in Mondrian related to the speed issue?
>
> Cheers,
> Alexandre
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
2:50 p.m.
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:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Alex,
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev > Indeed, this caching should happen for all
properties and for all shapes (both for nodes and for edges). I think that Alex stopped in
the middle because he did not know whether this caching had an effect or not.
I was wondering whether it would make sense to do this for all the metrics. Apparently
yes, I then continued. All shape parameters should be cached.
> Alex, could you take a look at that?
Done. Mondrian-Alexandre_Bergel.470
Great. I checked a bit the implementation, and I would only suggest to check for isCached
in the attributeAt:ifAbsent: method, instead of in every *For: methods.
> The next question is that if the border color
is called all the time, what is the use of the bitmap cache?
The bitmap is for not having to display inner nodes. Recursion takes times.
I know, but if you compute it once why do you still need to re-render?
Cheers,
Doru
>> ======
>> |view o |
>> view := MOViewRenderer new.
>> o := OrderedCollection new: 100.
>> 1 to: 100 do:[:i | o add: i].
>> (view shape: (MORectangleShape new
>> width: [:e | 200];
>> height: 200;
>> withBorder;
>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>> view nodes: o.
>> view layout: (MOGridLayout new gapSize: 1).
>> view open
>> ======
A better version could be
-=-=-=-=-=-=-=-=-=-=-=-=
|view o a |
a := {0}.
view := MOViewRenderer new.
o := OrderedCollection new: 100.
1 to: 100 do:[:i | o add: i].
(view shape: (MORectangleShape new
width: [:e | 200];
height: 200;
withBorder;
borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
view nodes: o.
view layout: (MOGridLayout new gapSize: 1).
view open.
a
-=-=-=-=-=-=-=-=-=-=-=-=
Just inspect the expression, and see if the array a changes over the time.
Is there any remaining problem left in Mondrian related to the speed issue?
Cheers,
Alexandre
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
2:51 p.m.
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Alex,
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev > Indeed, this caching should happen for all
properties and for all shapes (both for nodes and for edges). I think that Alex stopped in
the middle because he did not know whether this caching had an effect or not.
I was wondering whether it would make sense to do this for all the metrics. Apparently
yes, I then continued. All shape parameters should be cached.
> Alex, could you take a look at that?
Done. Mondrian-Alexandre_Bergel.470
Great. I checked a bit the implementation, and I would only suggest to check for isCached
in the attributeAt:ifAbsent: method, instead of in every *For: methods.
> The next question is that if the border color
is called all the time, what is the use of the bitmap cache?
The bitmap is for not having to display inner nodes. Recursion takes times.
I know, but if you compute it once why do you still need to re-render?
Cheers,
Doru
>> ======
>> |view o |
>> view := MOViewRenderer new.
>> o := OrderedCollection new: 100.
>> 1 to: 100 do:[:i | o add: i].
>> (view shape: (MORectangleShape new
>> width: [:e | 200];
>> height: 200;
>> withBorder;
>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>> view nodes: o.
>> view layout: (MOGridLayout new gapSize: 1).
>> view open
>> ======
A better version could be
-=-=-=-=-=-=-=-=-=-=-=-=
|view o a |
a := {0}.
view := MOViewRenderer new.
o := OrderedCollection new: 100.
1 to: 100 do:[:i | o add: i].
(view shape: (MORectangleShape new
width: [:e | 200];
height: 200;
withBorder;
borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
view nodes: o.
view layout: (MOGridLayout new gapSize: 1).
view open.
a
-=-=-=-=-=-=-=-=-=-=-=-=
Just inspect the expression, and see if the array a changes over the time.
Is there any remaining problem left in Mondrian related to the speed issue?
Cheers,
Alexandre
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
2:53 p.m.
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:
--
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I tested on a regular DSM with 259 namespaces and
I can now properly scroll once it gets displayed.
Jannik, Veronica, could you check in your cases?
Cheers,
Doru
On 17 Jun 2010, at 16:30, Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Alex,
>> Indeed, this caching should happen for all properties and for all shapes (both
for nodes and for edges). I think that Alex stopped in the middle because he did not know
whether this caching had an effect or not.
>
> I was wondering whether it would make sense to do this for all the metrics.
Apparently yes, I then continued. All shape parameters should be cached.
>> Alex, could you take a look at that?
>
> Done. Mondrian-Alexandre_Bergel.470
Great. I checked a bit the implementation, and I would only suggest to check for isCached
in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>> The next question is that if the border color is called all the time, what is the
use of the bitmap cache?
>
> The bitmap is for not having to display inner nodes. Recursion takes times.
I know, but if you compute it once why do you still need to re-render?
Cheers,
Doru
>>> ======
>>> |view o |
>>> view := MOViewRenderer new.
>>> o := OrderedCollection new: 100.
>>> 1 to: 100 do:[:i | o add: i].
>>> (view shape: (MORectangleShape new
>>> width: [:e | 200];
>>> height: 200;
>>> withBorder;
>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>> view nodes: o.
>>> view layout: (MOGridLayout new gapSize: 1).
>>> view open
>>> ======
>
> A better version could be
> -=-=-=-=-=-=-=-=-=-=-=-=
> |view o a |
> a := {0}.
> view := MOViewRenderer new.
> o := OrderedCollection new: 100.
> 1 to: 100 do:[:i | o add: i].
> (view shape: (MORectangleShape new
> width: [:e | 200];
> height: 200;
> withBorder;
> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
> view nodes: o.
> view layout: (MOGridLayout new gapSize: 1).
> view open.
> a
> -=-=-=-=-=-=-=-=-=-=-=-=
>
> Just inspect the expression, and see if the array a changes over the time.
>
> Is there any remaining problem left in Mondrian related to the speed issue?
>
> Cheers,
> Alexandre
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
3 p.m.
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:
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I tested on a regular DSM with 259 namespaces and
I can now properly scroll once it gets displayed.
Jannik, Veronica, could you check in your cases?
Cheers,
Doru
3:04 p.m.
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I tested on a regular DSM with 259 namespaces and
I can now properly scroll once it gets displayed.
Jannik, Veronica, could you check in your cases?
Cheers,
Doru
On 17 Jun 2010, at 16:30, Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Alex,
>> Indeed, this caching should happen for all properties and for all shapes (both
for nodes and for edges). I think that Alex stopped in the middle because he did not know
whether this caching had an effect or not.
>
> I was wondering whether it would make sense to do this for all the metrics.
Apparently yes, I then continued. All shape parameters should be cached.
>> Alex, could you take a look at that?
>
> Done. Mondrian-Alexandre_Bergel.470
Great. I checked a bit the implementation, and I would only suggest to check for isCached
in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>> The next question is that if the border color is called all the time, what is the
use of the bitmap cache?
>
> The bitmap is for not having to display inner nodes. Recursion takes times.
I know, but if you compute it once why do you still need to re-render?
Cheers,
Doru
>>> ======
>>> |view o |
>>> view := MOViewRenderer new.
>>> o := OrderedCollection new: 100.
>>> 1 to: 100 do:[:i | o add: i].
>>> (view shape: (MORectangleShape new
>>> width: [:e | 200];
>>> height: 200;
>>> withBorder;
>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>> view nodes: o.
>>> view layout: (MOGridLayout new gapSize: 1).
>>> view open
>>> ======
>
> A better version could be
> -=-=-=-=-=-=-=-=-=-=-=-=
> |view o a |
> a := {0}.
> view := MOViewRenderer new.
> o := OrderedCollection new: 100.
> 1 to: 100 do:[:i | o add: i].
> (view shape: (MORectangleShape new
> width: [:e | 200];
> height: 200;
> withBorder;
> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
> view nodes: o.
> view layout: (MOGridLayout new gapSize: 1).
> view open.
> a
> -=-=-=-=-=-=-=-=-=-=-=-=
>
> Just inspect the expression, and see if the array a changes over the time.
>
> Is there any remaining problem left in Mondrian related to the speed issue?
>
> Cheers,
> Alexandre
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3:26 p.m.
On 18 Jun 2010, at 14:53, Alexandre Bergel wrote:
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...
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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:
--
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I tested on a regular DSM with 259 namespaces and
I can now properly scroll once it gets displayed.
Jannik, Veronica, could you check in your cases?
Cheers,
Doru
On 17 Jun 2010, at 16:30, Tudor Girba wrote:
> Hi Alex,
>
>>> Indeed, this caching should happen for all properties and for all shapes
(both for nodes and for edges). I think that Alex stopped in the middle because he did not
know whether this caching had an effect or not.
>>
>> I was wondering whether it would make sense to do this for all the metrics.
Apparently yes, I then continued. All shape parameters should be cached.
>>> Alex, could you take a look at that?
>>
>> Done. Mondrian-Alexandre_Bergel.470
>
> Great. I checked a bit the implementation, and I would only suggest to check for
isCached in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>
>>> The next question is that if the border color is called all the time, what is
the use of the bitmap cache?
>>
>> The bitmap is for not having to display inner nodes. Recursion takes times.
>
> I know, but if you compute it once why do you still need to re-render?
>
> Cheers,
> Doru
>
>
>
>>>> ======
>>>> |view o |
>>>> view := MOViewRenderer new.
>>>> o := OrderedCollection new: 100.
>>>> 1 to: 100 do:[:i | o add: i].
>>>> (view shape: (MORectangleShape new
>>>> width: [:e | 200];
>>>> height: 200;
>>>> withBorder;
>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>>> view nodes: o.
>>>> view layout: (MOGridLayout new gapSize: 1).
>>>> view open
>>>> ======
>>
>> A better version could be
>> -=-=-=-=-=-=-=-=-=-=-=-=
>> |view o a |
>> a := {0}.
>> view := MOViewRenderer new.
>> o := OrderedCollection new: 100.
>> 1 to: 100 do:[:i | o add: i].
>> (view shape: (MORectangleShape new
>> width: [:e | 200];
>> height: 200;
>> withBorder;
>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>> view nodes: o.
>> view layout: (MOGridLayout new gapSize: 1).
>> view open.
>> a
>> -=-=-=-=-=-=-=-=-=-=-=-=
>>
>> Just inspect the expression, and see if the array a changes over the time.
>>
>> Is there any remaining problem left in Mondrian related to the speed issue?
>>
>> Cheers,
>> Alexandre
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3:44 p.m.
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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:
--
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I tested on a regular DSM with 259 namespaces and
I can now properly scroll once it gets displayed.
Jannik, Veronica, could you check in your cases?
Cheers,
Doru
On 17 Jun 2010, at 16:30, Tudor Girba wrote:
> Hi Alex,
>
>>> Indeed, this caching should happen for all properties and for all shapes
(both for nodes and for edges). I think that Alex stopped in the middle because he did not
know whether this caching had an effect or not.
>>
>> I was wondering whether it would make sense to do this for all the metrics.
Apparently yes, I then continued. All shape parameters should be cached.
>>> Alex, could you take a look at that?
>>
>> Done. Mondrian-Alexandre_Bergel.470
>
> Great. I checked a bit the implementation, and I would only suggest to check for
isCached in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>
>>> The next question is that if the border color is called all the time, what is
the use of the bitmap cache?
>>
>> The bitmap is for not having to display inner nodes. Recursion takes times.
>
> I know, but if you compute it once why do you still need to re-render?
>
> Cheers,
> Doru
>
>
>
>>>> ======
>>>> |view o |
>>>> view := MOViewRenderer new.
>>>> o := OrderedCollection new: 100.
>>>> 1 to: 100 do:[:i | o add: i].
>>>> (view shape: (MORectangleShape new
>>>> width: [:e | 200];
>>>> height: 200;
>>>> withBorder;
>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>>> view nodes: o.
>>>> view layout: (MOGridLayout new gapSize: 1).
>>>> view open
>>>> ======
>>
>> A better version could be
>> -=-=-=-=-=-=-=-=-=-=-=-=
>> |view o a |
>> a := {0}.
>> view := MOViewRenderer new.
>> o := OrderedCollection new: 100.
>> 1 to: 100 do:[:i | o add: i].
>> (view shape: (MORectangleShape new
>> width: [:e | 200];
>> height: 200;
>> withBorder;
>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>> view nodes: o.
>> view layout: (MOGridLayout new gapSize: 1).
>> view open.
>> a
>> -=-=-=-=-=-=-=-=-=-=-=-=
>>
>> Just inspect the expression, and see if the array a changes over the time.
>>
>> Is there any remaining problem left in Mondrian related to the speed issue?
>>
>> Cheers,
>> Alexandre
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
3:46 p.m.
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>
> --
> www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:29 p.m.
On 18 Jun 2010, at 15:44, Alexandre Bergel wrote:
this is hard to reproduce with single nodes only with nested nodes.... but the
difference is basically in the computation of textHeightFor:
MCBoundedShape manages this ok (labelShape was failing in that)
I meant the drawing method of MCLabelShape
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.
<Screen shot 2010-06-18 at 09.27.48.png>
Does it solve your issue?
I calculate the width a label uses before the drawing is done, for setting the width to
other nodes
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.
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>
> --
> www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:41 p.m.
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:
---
Jannik Laval
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:
--
www.tudorgirba.com
"It's not how it is, it is how we see it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I tested on a regular DSM with 259 namespaces and
I can now properly scroll once it gets displayed.
Jannik, Veronica, could you check in your cases?
Cheers,
Doru
On 17 Jun 2010, at 16:30, Tudor Girba wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Alex,
>> Indeed, this caching should happen for all properties and for all shapes (both
for nodes and for edges). I think that Alex stopped in the middle because he did not know
whether this caching had an effect or not.
>
> I was wondering whether it would make sense to do this for all the metrics.
Apparently yes, I then continued. All shape parameters should be cached.
>> Alex, could you take a look at that?
>
> Done. Mondrian-Alexandre_Bergel.470
Great. I checked a bit the implementation, and I would only suggest to check for isCached
in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>> The next question is that if the border color is called all the time, what is the
use of the bitmap cache?
>
> The bitmap is for not having to display inner nodes. Recursion takes times.
I know, but if you compute it once why do you still need to re-render?
Cheers,
Doru
>>> ======
>>> |view o |
>>> view := MOViewRenderer new.
>>> o := OrderedCollection new: 100.
>>> 1 to: 100 do:[:i | o add: i].
>>> (view shape: (MORectangleShape new
>>> width: [:e | 200];
>>> height: 200;
>>> withBorder;
>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>> view nodes: o.
>>> view layout: (MOGridLayout new gapSize: 1).
>>> view open
>>> ======
>
> A better version could be
> -=-=-=-=-=-=-=-=-=-=-=-=
> |view o a |
> a := {0}.
> view := MOViewRenderer new.
> o := OrderedCollection new: 100.
> 1 to: 100 do:[:i | o add: i].
> (view shape: (MORectangleShape new
> width: [:e | 200];
> height: 200;
> withBorder;
> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
> view nodes: o.
> view layout: (MOGridLayout new gapSize: 1).
> view open.
> a
> -=-=-=-=-=-=-=-=-=-=-=-=
>
> Just inspect the expression, and see if the array a changes over the time.
>
> Is there any remaining problem left in Mondrian related to the speed issue?
>
> Cheers,
> Alexandre
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:11 p.m.
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:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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:
--
www.tudorgirba.com
"It's not how it is, it is how we see it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I tested on a regular DSM with 259 namespaces and
I can now properly scroll once it gets displayed.
Jannik, Veronica, could you check in your cases?
Cheers,
Doru
On 17 Jun 2010, at 16:30, Tudor Girba wrote:
> Hi Alex,
>
>>> Indeed, this caching should happen for all properties and for all shapes
(both for nodes and for edges). I think that Alex stopped in the middle because he did not
know whether this caching had an effect or not.
>>
>> I was wondering whether it would make sense to do this for all the metrics.
Apparently yes, I then continued. All shape parameters should be cached.
>>> Alex, could you take a look at that?
>>
>> Done. Mondrian-Alexandre_Bergel.470
>
> Great. I checked a bit the implementation, and I would only suggest to check for
isCached in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>
>>> The next question is that if the border color is called all the time, what is
the use of the bitmap cache?
>>
>> The bitmap is for not having to display inner nodes. Recursion takes times.
>
> I know, but if you compute it once why do you still need to re-render?
>
> Cheers,
> Doru
>
>
>
>>>> ======
>>>> |view o |
>>>> view := MOViewRenderer new.
>>>> o := OrderedCollection new: 100.
>>>> 1 to: 100 do:[:i | o add: i].
>>>> (view shape: (MORectangleShape new
>>>> width: [:e | 200];
>>>> height: 200;
>>>> withBorder;
>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>>> view nodes: o.
>>>> view layout: (MOGridLayout new gapSize: 1).
>>>> view open
>>>> ======
>>
>> A better version could be
>> -=-=-=-=-=-=-=-=-=-=-=-=
>> |view o a |
>> a := {0}.
>> view := MOViewRenderer new.
>> o := OrderedCollection new: 100.
>> 1 to: 100 do:[:i | o add: i].
>> (view shape: (MORectangleShape new
>> width: [:e | 200];
>> height: 200;
>> withBorder;
>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>> view nodes: o.
>> view layout: (MOGridLayout new gapSize: 1).
>> view open.
>> a
>> -=-=-=-=-=-=-=-=-=-=-=-=
>>
>> Just inspect the expression, and see if the array a changes over the time.
>>
>> Is there any remaining problem left in Mondrian related to the speed issue?
>>
>> Cheers,
>> Alexandre
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:13 p.m.
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:
--
www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot
be done."
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>
> --
> www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:28 p.m.
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:
---
Jannik Laval
strange models
sometimes you cannot rely on the data extracted.
On Jun 18, 2010, at 4:41 PM, Laval Jannik wrote:
--
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Some battles are better lost than fought."
>>>
>>>
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> ---
> Jannik Laval
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:37 p.m.
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:
--
www.tudorgirba.com
"Live like you mean it."
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:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev strange models
sometimes you cannot rely on the data extracted.
On Jun 18, 2010, at 4:41 PM, Laval Jannik wrote:
--
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Some battles are better lost than fought."
>>>>
>>>>
>>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Some battles are better lost than fought."
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> ---
>> Jannik Laval
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:17 p.m.
Hi Alex,
There is something I do not understand.
Why do you use a cache and not the state of the object ?
Isn't it more efficient to store values in instance variable instead of a cache
construct with a collection, or another complex structure.
I'm sure you use cache for good reasons,
and maybe my vision is too naive.
But we have several problems which will appear in a near future:
- if we do not use cache, visualization is slow.
- if we use a cache, the space used by pharo will explode (for now, in a vm with original
parameters, it is not possible to load 7 times the MooseModel of Moose itself)
Now, if we have a state for a shape, there are no problem of cache or of refresh.
But as I said before, my vision is maybe too naive.
Please, explain your choice :)
Thank you
Cheers,
Jannik
PS: for a result, eDSM is always slow, so some parameters are not cached anymore ?
On Jun 18, 2010, at 14:50 , Alexandre Bergel wrote:
---
Jannik Laval
Alex, do you
cache all things ?
All the parameters in a shape that could be cached are now cached (e.g., width: height:
fillColor: borderColor: ...)
Cheers,
Alexandre
Thanks,
Jannik
On Jun 17, 2010, at 17:47 , Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I tested on a regular DSM with 259 namespaces and
I can now properly scroll once it gets displayed.
Jannik, Veronica, could you check in your cases?
Cheers,
Doru
On 17 Jun 2010, at 16:30, Tudor Girba wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Alex,
>> Indeed, this caching should happen for all properties and for all shapes (both
for nodes and for edges). I think that Alex stopped in the middle because he did not know
whether this caching had an effect or not.
>
> I was wondering whether it would make sense to do this for all the metrics.
Apparently yes, I then continued. All shape parameters should be cached.
>> Alex, could you take a look at that?
>
> Done. Mondrian-Alexandre_Bergel.470
Great. I checked a bit the implementation, and I would only suggest to check for isCached
in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>> The next question is that if the border color is called all the time, what is the
use of the bitmap cache?
>
> The bitmap is for not having to display inner nodes. Recursion takes times.
I know, but if you compute it once why do you still need to re-render?
Cheers,
Doru
>>> ======
>>> |view o |
>>> view := MOViewRenderer new.
>>> o := OrderedCollection new: 100.
>>> 1 to: 100 do:[:i | o add: i].
>>> (view shape: (MORectangleShape new
>>> width: [:e | 200];
>>> height: 200;
>>> withBorder;
>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>> view nodes: o.
>>> view layout: (MOGridLayout new gapSize: 1).
>>> view open
>>> ======
>
> A better version could be
> -=-=-=-=-=-=-=-=-=-=-=-=
> |view o a |
> a := {0}.
> view := MOViewRenderer new.
> o := OrderedCollection new: 100.
> 1 to: 100 do:[:i | o add: i].
> (view shape: (MORectangleShape new
> width: [:e | 200];
> height: 200;
> withBorder;
> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
> view nodes: o.
> view layout: (MOGridLayout new gapSize: 1).
> view open.
> a
> -=-=-=-=-=-=-=-=-=-=-=-=
>
> Just inspect the expression, and see if the array a changes over the time.
>
> Is there any remaining problem left in Mondrian related to the speed issue?
>
> Cheers,
> Alexandre
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:31 p.m.
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:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow."
Alex, do
you cache all things ?
All the parameters in a shape that could be cached are now cached
(e.g., width: height: fillColor: borderColor: ...)
Cheers,
Alexandre
Thanks,
Jannik
On Jun 17, 2010, at 17:47 , Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I tested on a regular DSM with 259 namespaces and
I can now
properly scroll once it gets displayed.
Jannik, Veronica, could you check in your cases?
Cheers,
Doru
On 17 Jun 2010, at 16:30, Tudor Girba wrote:
> Hi Alex,
>
>>> Indeed, this caching should happen for all properties and for
>>> all shapes (both for nodes and for edges). I think that Alex
>>> stopped in the middle because he did not know whether this
>>> caching had an effect or not.
>>
>> I was wondering whether it would make sense to do this for all
>> the metrics. Apparently yes, I then continued. All shape
>> parameters should be cached.
>>> Alex, could you take a look at that?
>>
>> Done. Mondrian-Alexandre_Bergel.470
>
> Great. I checked a bit the implementation, and I would only
> suggest to check for isCached in the attributeAt:ifAbsent:
> method, instead of in every *For: methods.
>
>>> The next question is that if the border color is called all
>>> the time, what is the use of the bitmap cache?
>>
>> The bitmap is for not having to display inner nodes. Recursion
>> takes times.
>
> I know, but if you compute it once why do you still need to re-
> render?
>
> Cheers,
> Doru
>
>
>
>>>> ======
>>>> |view o |
>>>> view := MOViewRenderer new.
>>>> o := OrderedCollection new: 100.
>>>> 1 to: 100 do:[:i | o add: i].
>>>> (view shape: (MORectangleShape new
>>>> width: [:e | 200];
>>>> height: 200;
>>>> withBorder;
>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color
>>>> gray])).
>>>> view nodes: o.
>>>> view layout: (MOGridLayout new gapSize: 1).
>>>> view open
>>>> ======
>>
>> A better version could be
>> -=-=-=-=-=-=-=-=-=-=-=-=
>> |view o a |
>> a := {0}.
>> view := MOViewRenderer new.
>> o := OrderedCollection new: 100.
>> 1 to: 100 do:[:i | o add: i].
>> (view shape: (MORectangleShape new
>> width: [:e | 200];
>> height: 200;
>> withBorder;
>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>> view nodes: o.
>> view layout: (MOGridLayout new gapSize: 1).
>> view open.
>> a
>> -=-=-=-=-=-=-=-=-=-=-=-=
>>
>> Just inspect the expression, and see if the array a changes
>> over the time.
>>
>> Is there any remaining problem left in Mondrian related to the
>> speed issue?
>>
>> Cheers,
>> Alexandre
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
19 Jun
19 Jun
8:02 a.m.
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:
---
Jannik Laval
Hi Alex,
There is something I do not understand.
Why do you use a cache and not the state of the object ?
Isn't it more efficient to store values in instance variable instead of a cache
construct with a collection, or another complex structure.
I'm sure you use cache for good reasons,
and maybe my vision is too naive.
But we have several problems which will appear in a near future:
- if we do not use cache, visualization is slow.
- if we use a cache, the space used by pharo will explode (for now, in a vm with original
parameters, it is not possible to load 7 times the MooseModel of Moose itself)
Now, if we have a state for a shape, there are no problem of cache or of refresh.
But as I said before, my vision is maybe too naive.
Please, explain your choice :)
Thank you
Cheers,
Jannik
PS: for a result, eDSM is always slow, so some parameters are not cached anymore ?
On Jun 18, 2010, at 14:50 , Alexandre Bergel wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>
> --
> www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:03 a.m.
Hi Jannik,
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.
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.
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.
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
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
--
www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting
is the right one."
Cheers,
Doru
On 18 Jun 2010, at 22:17, Laval Jannik wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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:
--
www.tudorgirba.com
"Every thing has its own flow."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev > 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(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Some battles are better lost than fought."
>>>
>>>
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> ---
> Jannik Laval
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2:15 p.m.
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,
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.
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.
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.
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
---
Jannik Laval
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
--
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Cheers,
Doru
On 18 Jun 2010, at 22:17, Laval Jannik wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Some battles are better lost than fought."
>>>>
>>>>
>>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Some battles are better lost than fought."
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> ---
>> Jannik Laval
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2:25 p.m.
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
2:31 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"What we can governs what we wish."
2:43 p.m.
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:
---
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
20 Jun
20 Jun
6:33 p.m.
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 ?
On 18 Jun 2010, at 22:17, Laval Jannik wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Some battles are better lost than fought."
>>>>
>>>>
>>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Some battles are better lost than fought."
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> ---
>> Jannik Laval
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
6:54 p.m.
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:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
22 Jun
22 Jun
12:54 a.m.
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:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
7:08 a.m.
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:
---
Jannik Laval
On Jun 19, 2010, at 14:31 , Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:45 a.m.
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:
--
www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
On Jun 19, 2010, at 14:31 , Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:30 a.m.
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:
---
Jannik Laval
On Jun 19, 2010, at 14:31 , Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:26 p.m.
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:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jun 19, 2010, at 14:31 , Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:27 p.m.
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 :)? Cheers,
Alexandre
<Screen shot 2010-06-21 at 18.52.20.png>
On 19 Jun 2010, at 08:43, Laval Jannik wrote:
--
www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jun 19, 2010, at 14:31 , Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5051
days inactive
5057
days old
42 comments
6 participants
participants (6)
-
Alexandre Bergel -
Johan Fabry -
Laval Jannik -
Stéphane Ducasse -
Tudor Girba -
Veronica Isabel Uquillas Gomez