thanks alex we are really stressing mondrian with our crazy ideas.

On Jul 16, 2010, at 9:31 AM, Alexandre Bergel wrote: > Dear Mondrian friends, > > A new cache mechanism has been implemented and some part have been simplified. The goal was to make Package blueprint fast without reducing the speed up for other visualization. The goal has been reached. On my machine, Package Blueprint is snappy (as soon as it got displayed and you do not select anything). > > The health report shown below is sensibly the same than the one sent few days ago. However, the new benchmark ("Benchmark many small nodes") is the one that reproduce a situation found in package blueprint. It was costly before this version. > > I would like you to try the last version of Mondrian. I tested it against class blueprint and it behaves as it should. However, you may notice some differences. Was the rendering and scrolling faster for you? Are you happy with this new version? > > > Report produced on 2010-07-16T09:13:19+02:00 > System version Pharo-1.1-11400-rc2 of 12 June 2010 update 11400 > Benchmark ManyNode (simple rendering of nodes) : > 100 nodes => 7 ms > 200 nodes => 12 ms > 300 nodes => 18 ms > 400 nodes => 23 ms > 500 nodes => 30 ms > 600 nodes => 35 ms > 700 nodes => 41 ms > 800 nodes => 46 ms > 900 nodes => 52 ms > 1000 nodes => 58 ms > 1600 nodes => 93 ms > 3200 nodes => 186 ms > 6400 nodes => 373 ms > Benchmark ManyEdges (simple rendering of edges) : > 10 edges => 3 ms > 20 edges => 9 ms > 30 edges => 21 ms > 40 edges => 38 ms > 50 edges => 65 ms > 60 edges => 102 ms > 70 edges => 153 ms > 80 edges => 223 ms > 90 edges => 310 ms > 100 edges => 409 ms > 200 edges => 5844 ms > 300 edges => 37619 ms > Benchmark ManyInnerNodes : > 5 nodes => 170 ms > 10 nodes => 3012 ms > 15 nodes => 11589 ms > Benchmark Displaying ManyInnerNodes : > 5 nodes => 152 ms > 10 nodes => 1526 ms > 15 nodes => 11186 ms > Benchmark Displaying ManyInnerNodesAndEdges : > 1 nodes => 9 ms > 2 nodes => 239 ms > 3 nodes => 3278 ms > 4 nodes => 30492 ms > Benchmark Displaying elementAt : > 100 nodes => 3 ms > 500 nodes => 5 ms > 1000 nodes => 9 ms > 1500 nodes => 11 ms > 2000 nodes => 14 ms > 2500 nodes => 16 ms > Benchmark many small nodes : > 2000 nodes => 2368 ms > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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

Hi Alex, The new version creates serious problems for system complexity: everything appears double. See the attachment. Also, in the blueprint, the bounds are again cropping the top and the left side of the visualization. I tested both with the Cog and with regular VM. Cheers, Doru <Picture 1.png> On 16 Jul 2010, at 10:27, Alexandre Bergel wrote: >> thanks alex >> we are really stressing mondrian with our crazy ideas. > > Package blueprint was indeed interesting. > Thousands of small nodes contained in a large node, big enough to not be cached using the former system. Large nodes are now bitmap cached even if they are partially displayed. It looks obvious, but converging to this solution took time... > > Thanks for all your bug report. > > Cheers, > Alexandre > >> >> On Jul 16, 2010, at 9:31 AM, Alexandre Bergel wrote: >> >>> Dear Mondrian friends, >>> >>> A new cache mechanism has been implemented and some part have been simplified. The goal was to make Package blueprint fast without reducing the speed up for other visualization. The goal has been reached. On my machine, Package Blueprint is snappy (as soon as it got displayed and you do not select anything). >>> >>> The health report shown below is sensibly the same than the one sent few days ago. However, the new benchmark ("Benchmark many small nodes") is the one that reproduce a situation found in package blueprint. It was costly before this version. >>> >>> I would like you to try the last version of Mondrian. I tested it against class blueprint and it behaves as it should. However, you may notice some differences. Was the rendering and scrolling faster for you? Are you happy with this new version? >>> >>> >>> Report produced on 2010-07-16T09:13:19+02:00 >>> System version Pharo-1.1-11400-rc2 of 12 June 2010 update 11400 >>> Benchmark ManyNode (simple rendering of nodes) : >>> 100 nodes => 7 ms >>> 200 nodes => 12 ms >>> 300 nodes => 18 ms >>> 400 nodes => 23 ms >>> 500 nodes => 30 ms >>> 600 nodes => 35 ms >>> 700 nodes => 41 ms >>> 800 nodes => 46 ms >>> 900 nodes => 52 ms >>> 1000 nodes => 58 ms >>> 1600 nodes => 93 ms >>> 3200 nodes => 186 ms >>> 6400 nodes => 373 ms >>> Benchmark ManyEdges (simple rendering of edges) : >>> 10 edges => 3 ms >>> 20 edges => 9 ms >>> 30 edges => 21 ms >>> 40 edges => 38 ms >>> 50 edges => 65 ms >>> 60 edges => 102 ms >>> 70 edges => 153 ms >>> 80 edges => 223 ms >>> 90 edges => 310 ms >>> 100 edges => 409 ms >>> 200 edges => 5844 ms >>> 300 edges => 37619 ms >>> Benchmark ManyInnerNodes : >>> 5 nodes => 170 ms >>> 10 nodes => 3012 ms >>> 15 nodes => 11589 ms >>> Benchmark Displaying ManyInnerNodes : >>> 5 nodes => 152 ms >>> 10 nodes => 1526 ms >>> 15 nodes => 11186 ms >>> Benchmark Displaying ManyInnerNodesAndEdges : >>> 1 nodes => 9 ms >>> 2 nodes => 239 ms >>> 3 nodes => 3278 ms >>> 4 nodes => 30492 ms >>> Benchmark Displaying elementAt : >>> 100 nodes => 3 ms >>> 500 nodes => 5 ms >>> 1000 nodes => 9 ms >>> 1500 nodes => 11 ms >>> 2000 nodes => 14 ms >>> 2500 nodes => 16 ms >>> Benchmark many small nodes : >>> 2000 nodes => 2368 ms >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "What is more important: To be happy, or to make happy?" _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Yes, I reproduce it. In a small system complexity, the problem does not appear (Network) In Seaside, a big one (1100 classes), I have the same bug as Doru. Jannik On Jul 16, 2010, at 11:17 , Alexandre Bergel wrote: > Strange. I cannot reproduce the issue. > It works properly with me. > > Jannik, can you try to open a system complexity please? > > Cheers, > Alexandre > > > On 16 Jul 2010, at 10:56, Tudor Girba wrote: > >> Hi Alex, >> >> The new version creates serious problems for system complexity: everything appears double. See the attachment. >> >> Also, in the blueprint, the bounds are again cropping the top and the left side of the visualization. >> >> I tested both with the Cog and with regular VM. >> >> Cheers, >> Doru >> >> <Picture 1.png> >> >> >> >> On 16 Jul 2010, at 10:27, Alexandre Bergel wrote: >> >>>> thanks alex >>>> we are really stressing mondrian with our crazy ideas. >>> >>> Package blueprint was indeed interesting. >>> Thousands of small nodes contained in a large node, big enough to not be cached using the former system. Large nodes are now bitmap cached even if they are partially displayed. It looks obvious, but converging to this solution took time... >>> >>> Thanks for all your bug report. >>> >>> Cheers, >>> Alexandre >>> >>>> >>>> On Jul 16, 2010, at 9:31 AM, Alexandre Bergel wrote: >>>> >>>>> Dear Mondrian friends, >>>>> >>>>> A new cache mechanism has been implemented and some part have been simplified. The goal was to make Package blueprint fast without reducing the speed up for other visualization. The goal has been reached. On my machine, Package Blueprint is snappy (as soon as it got displayed and you do not select anything). >>>>> >>>>> The health report shown below is sensibly the same than the one sent few days ago. However, the new benchmark ("Benchmark many small nodes") is the one that reproduce a situation found in package blueprint. It was costly before this version. >>>>> >>>>> I would like you to try the last version of Mondrian. I tested it against class blueprint and it behaves as it should. However, you may notice some differences. Was the rendering and scrolling faster for you? Are you happy with this new version? >>>>> >>>>> >>>>> Report produced on 2010-07-16T09:13:19+02:00 >>>>> System version Pharo-1.1-11400-rc2 of 12 June 2010 update 11400 >>>>> Benchmark ManyNode (simple rendering of nodes) : >>>>> 100 nodes => 7 ms >>>>> 200 nodes => 12 ms >>>>> 300 nodes => 18 ms >>>>> 400 nodes => 23 ms >>>>> 500 nodes => 30 ms >>>>> 600 nodes => 35 ms >>>>> 700 nodes => 41 ms >>>>> 800 nodes => 46 ms >>>>> 900 nodes => 52 ms >>>>> 1000 nodes => 58 ms >>>>> 1600 nodes => 93 ms >>>>> 3200 nodes => 186 ms >>>>> 6400 nodes => 373 ms >>>>> Benchmark ManyEdges (simple rendering of edges) : >>>>> 10 edges => 3 ms >>>>> 20 edges => 9 ms >>>>> 30 edges => 21 ms >>>>> 40 edges => 38 ms >>>>> 50 edges => 65 ms >>>>> 60 edges => 102 ms >>>>> 70 edges => 153 ms >>>>> 80 edges => 223 ms >>>>> 90 edges => 310 ms >>>>> 100 edges => 409 ms >>>>> 200 edges => 5844 ms >>>>> 300 edges => 37619 ms >>>>> Benchmark ManyInnerNodes : >>>>> 5 nodes => 170 ms >>>>> 10 nodes => 3012 ms >>>>> 15 nodes => 11589 ms >>>>> Benchmark Displaying ManyInnerNodes : >>>>> 5 nodes => 152 ms >>>>> 10 nodes => 1526 ms >>>>> 15 nodes => 11186 ms >>>>> Benchmark Displaying ManyInnerNodesAndEdges : >>>>> 1 nodes => 9 ms >>>>> 2 nodes => 239 ms >>>>> 3 nodes => 3278 ms >>>>> 4 nodes => 30492 ms >>>>> Benchmark Displaying elementAt : >>>>> 100 nodes => 3 ms >>>>> 500 nodes => 5 ms >>>>> 1000 nodes => 9 ms >>>>> 1500 nodes => 11 ms >>>>> 2000 nodes => 14 ms >>>>> 2500 nodes => 16 ms >>>>> Benchmark many small nodes : >>>>> 2000 nodes => 2368 ms >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "What is more important: To be happy, or to make happy?" >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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