Re: [racket-users] performance with freeze from 2htdp/image on very complex images
Good news! With the add-line change that freeze operation on that huge fractal finished! time(img-expr): cpu time: 1552529 real time: 1567217 gc time: 576576 time(freeze(img)) : cpu time: 26904587 real time: 79234417 gc time: 20568080 What is that, about 7 and a half hours of cpu time, about 22 hours of real time, and about 5.7 hours of gc time? Compared to not even finishing after running for 3 days though, that’s great! https://github.com/AlexKnauth/koch-snowflake/commit/aed7e1ba864ea8a56f3fe296bc684e65d5ee9aa0 On May 5, 2015, at 10:06 AM, Robby Findler ro...@eecs.northwestern.edu wrote: One of the issues is that the racket/draw version is not doing the cropping that the 2htdp/image version is doing. Changing the scene+line call in utils.rkt to add-line cuts the freeze time in half for me (using size 242 instead of 728 in the time.rkt file). I didn't check to see if lines go outside the shape, but if they do, you might consider just using some arithmetic comparisons there in util.rkt instead. With that change, then I see the time for freezing being the same as the time for the racket/draw version to draw. I tried to find ways to speed up the construction of the image, but I didn't find anything that makes a useful change. It seems like just constructing the data structure that represents the shape has a basic cost and I didn't find any simple ways to improve the situation inside the library. (I tried to cut some corners in add-line but to no avail.) Sorry, Robby On Mon, May 4, 2015 at 10:33 PM, Alexander D. Knauth alexan...@knauth.org wrote: On May 4, 2015, at 6:02 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Another approach here would be to help me do performance debugging of 2htdp/image :). You could write the code directly as imperative calls to the dc% interface and see how that compares. If there's a significant difference, that suggests we might be able to find a way to speed up 2htdp/image. I tried doing that, and here’s what I got: (time (snowflake/inner-fractal 728)) : cpu time: 14775 real time: 14874 gc time: 2304 (time (freeze img1)) : cpu time: 377110 real time: 377867 gc time: 198343 (time (snowflake/inner-fractal/draw 728)) : cpu time: 24257 real time: 24267 gc time: 5852 Where snowflake/inner-fractal uses 2htdp/image, the result of that call is defined as img1, and snowflake/inner-fractal/draw uses racket/draw. The program that produces this output is here: https://github.com/AlexKnauth/koch-snowflake/blob/master/try-draw/time.rkt -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] performance with freeze from 2htdp/image on very complex images
One of the issues is that the racket/draw version is not doing the cropping that the 2htdp/image version is doing. Changing the scene+line call in utils.rkt to add-line cuts the freeze time in half for me (using size 242 instead of 728 in the time.rkt file). I didn't check to see if lines go outside the shape, but if they do, you might consider just using some arithmetic comparisons there in util.rkt instead. With that change, then I see the time for freezing being the same as the time for the racket/draw version to draw. I tried to find ways to speed up the construction of the image, but I didn't find anything that makes a useful change. It seems like just constructing the data structure that represents the shape has a basic cost and I didn't find any simple ways to improve the situation inside the library. (I tried to cut some corners in add-line but to no avail.) Sorry, Robby On Mon, May 4, 2015 at 10:33 PM, Alexander D. Knauth alexan...@knauth.org wrote: On May 4, 2015, at 6:02 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Another approach here would be to help me do performance debugging of 2htdp/image :). You could write the code directly as imperative calls to the dc% interface and see how that compares. If there's a significant difference, that suggests we might be able to find a way to speed up 2htdp/image. I tried doing that, and here’s what I got: (time (snowflake/inner-fractal 728)) : cpu time: 14775 real time: 14874 gc time: 2304 (time (freeze img1)) : cpu time: 377110 real time: 377867 gc time: 198343 (time (snowflake/inner-fractal/draw 728)) : cpu time: 24257 real time: 24267 gc time: 5852 Where snowflake/inner-fractal uses 2htdp/image, the result of that call is defined as img1, and snowflake/inner-fractal/draw uses racket/draw. The program that produces this output is here: https://github.com/AlexKnauth/koch-snowflake/blob/master/try-draw/time.rkt -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] performance with freeze from 2htdp/image on very complex images
On May 5, 2015, at 10:06 AM, Robby Findler ro...@eecs.northwestern.edu wrote: One of the issues is that the racket/draw version is not doing the cropping that the 2htdp/image version is doing. Changing the scene+line call in utils.rkt to add-line cuts the freeze time in half for me (using size 242 instead of 728 in the time.rkt file). I didn't check to see if lines go outside the shape, but if they do, you might consider just using some arithmetic comparisons there in util.rkt instead. At first, I was using add-line, but then switched to scene+line because at first the lines were sometimes going outside the shape, and when that happened on the left (or the top), it would effectively shift the whole image to the right, but it would still draw the next line too far left, shifting the rest of the image even more right, and I ended up with an image with a little bit of what I wanted on the far right, and a little bit of what I wanted on the far left, and in between a trail of tiny lines oriented in weird directions. I had kind of assumed that scene+line might be faster because it could be “translated” into just adding a line to a bitmap, while I thought add-line would be slightly more expensive because it had to adjust the bounding box when it went outside the image, but I guess I was wrong. So thanks for the suggestion! With that change, then I see the time for freezing being the same as the time for the racket/draw version to draw. That’s not what I see for size 728: (time (snowflake/inner-fractal 728)) : cpu time: 14822 real time: 14847 gc time: 2327 (time (freeze img1)) : cpu time: 197506 real time: 197911 gc time: 102407 (time (snowflake/inner-fractal/draw 728)) : cpu time: 23638 real time: 23646 gc time: 5495 Where before it was: (time (snowflake/inner-fractal 728)) : cpu time: 14775 real time: 14874 gc time: 2304 (time (freeze img1)) : cpu time: 377110 real time: 377867 gc time: 198343 (time (snowflake/inner-fractal/draw 728)) : cpu time: 24257 real time: 24267 gc time: 5852 So it did significantly reduce the time for freezing it, but it’s still about 8 times slower than using racket/draw. Alex Knauth -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] performance with freeze from 2htdp/image on very complex images
On May 4, 2015, at 6:02 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Another approach here would be to help me do performance debugging of 2htdp/image :). You could write the code directly as imperative calls to the dc% interface and see how that compares. If there's a significant difference, that suggests we might be able to find a way to speed up 2htdp/image. I tried doing that, and here’s what I got: (time (snowflake/inner-fractal 728)) : cpu time: 14775 real time: 14874 gc time: 2304 (time (freeze img1)) : cpu time: 377110 real time: 377867 gc time: 198343 (time (snowflake/inner-fractal/draw 728)) : cpu time: 24257 real time: 24267 gc time: 5852 Where snowflake/inner-fractal uses 2htdp/image, the result of that call is defined as img1, and snowflake/inner-fractal/draw uses racket/draw. The program that produces this output is here: https://github.com/AlexKnauth/koch-snowflake/blob/master/try-draw/time.rkt -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
