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
"What is more important: To be happy, or to make happy?"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch