Re: [racket-users] performance with freeze from 2htdp/image on very complex images
I played around with this for a while, but I've not been able to figure out a change that makes a positive impact. One experiment that seemed useful: I put a printf of the result of current-process-milliseconds right by the code that calls draw-line in your code and in 2htdp/image (which is in the mrlib/core library, the cond clause for line-segment? on line 984). In your code, the printf happens, on average, every .10 millisecond and in 2thdp/image it happens every .63 milliseconds, which is exactly the same ratio I see for the drawing vs the freezing. I tried to change your code to use a dc-path, the way that the 2htdp/image code does, and that gave a 50% slowdown (from 12 to 18 seconds), which isn't close to the factor of 6 between the two programs. I also just disabled the actual drawing (commenting out the line that does the draw-path call) in 2thdp/image and this gave a factor of three improvement. So it is something other than the actual drawing that's going on here. There is a contract nearby that gets checked alot, but removing it has no impact. I wondered if the fact that the 2htdp/image library is building a giant data structure and then traversing it once might cause a slowdown at a lower layer (just because it touchs a lot of different parts of the memory) but I don't know how to do a measurement that could answer that question. I guess you could use "pin" or "cachegrind" but I didn't try that. (I think cachegrind doesn't work with Racket and pin is very much non-trivial to set up.) There might be a way to instrument the GC to get some of that information back, but that also sounds non-trivial. I tried just freezing img1 three times in a row, but that didn't make much difference, so probably that's not it. Otherwise, I'm out of ideas. Robby On Tue, May 5, 2015 at 2:55 PM, Alexander D. Knauth wrote: > > On May 5, 2015, at 10:06 AM, Robby Findler > 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
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 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 > wrote: >> >> On May 4, 2015, at 6:02 PM, Robby Findler >> 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
On May 5, 2015, at 10:06 AM, Robby Findler 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
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 wrote: > > On May 4, 2015, at 6:02 PM, Robby Findler > 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 4, 2015, at 6:02 PM, Robby Findler 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 4, 2015, at 6:02 PM, Robby Findler wrote: > It certainly can lose sharpness if you scale (as the freezing process > is basically just rendering them into bitmaps and then drawing the > bitmaps and scaling the bitmaps looses quality because the scaling for > process of bitmaps doesn't have the geometric information to work > with). Sorry, that’s not what I mean’t by sharpness. I mean that the tips of the fractal look rounded to me; probably something to do with the bounding boxes of rotated images, and how they interact when put beside one another? Anyway it looked to me like something that could mess up how the layers lined up, so that’s why I used the approach I did. > It seems like, with fractals, the fact that you have self-similarity > means that you can have repeated images in a dag-like structure (like > the example on the webpage) where freezing might help. But since they’re all rotated from one another, would it still help? The documentation says it doesn’t help when it will be rotated, and I can imagine why. > 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 think once I finish this English paper that’s what I’ll do. > You'd use something like this: > > #lang racket/gui > > (define (draw-it dc w h) > ;; fractal drawing code goes here > (send dc draw-ellipse (/ w 4) (/ h 4) (/ w 2) (/ h 2))) > > (define f (new frame% [label ""] [width 200] [height 200])) > (define c (new canvas% [parent f] > [paint-callback >(λ (c dc) > (define-values (w h) (send c get-client-size)) > (send dc set-smoothing 'aligned) > (draw-it dc w h))])) > (send f show #t) -- 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
It certainly can lose sharpness if you scale (as the freezing process is basically just rendering them into bitmaps and then drawing the bitmaps and scaling the bitmaps looses quality because the scaling for process of bitmaps doesn't have the geometric information to work with). It seems like, with fractals, the fact that you have self-similarity means that you can have repeated images in a dag-like structure (like the example on the webpage) where freezing might help. 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. You'd use something like this: #lang racket/gui (define (draw-it dc w h) ;; fractal drawing code goes here (send dc draw-ellipse (/ w 4) (/ h 4) (/ w 2) (/ h 2))) (define f (new frame% [label ""] [width 200] [height 200])) (define c (new canvas% [parent f] [paint-callback (λ (c dc) (define-values (w h) (send c get-client-size)) (send dc set-smoothing 'aligned) (draw-it dc w h))])) (send f show #t) On Mon, May 4, 2015 at 4:03 PM, Alexander D. Knauth wrote: > > On May 4, 2015, at 12:49 AM, gfb wrote: > >> Those are beautiful. > > Thanks! > >> First, make sure in Choose Language / Show Details that it's set to "No >> debugging or profiling", and that "Preserve stacktrace" not set. > > Already have that, but thanks for checking. > >> The 2htdp/image library has immutable images, so the image you're creating >> contains all the line drawing "unexecuted" until you display or freeze it. >> >> There's a lot of symmetry, so rather than passing an image as a parameter >> can you express the algorithm as returning one of the component images at >> each level, then rotating and combining it with itself? As long as the >> result is symmetric that will create a rather narrow Direct Acyclic Graph of >> images. > > I thought about doing that, and that’s what an example in the docs does, but > I didn’t because I was afraid I would lose precision of exactly where the > lines go, and since most of these fractals have multiple layers, that’s > important. > From the example in the docs, at the smaller scales it doesn’t look sharp or > accurate to me, and would it really improve performance? Since they would be > all rotated from each other, I don’t think I would be able to reuse > computations very much. > >> You can then also experiment with freezing some of those intermediate >> images, especially at the top levels where rotating a bitmap might be faster >> than executing the drawing actions in a rotated co-ordinate system. But >> that's speculation, not experience. > > The documentation for freeze says that freeze isn’t going to be helpful for > images that will be scaled or rotated? > If it were a serpinski carpet, I think this could probably help a lot, but > for what I’m doing, I don’t think it would. > >> Other than that, consider drawing directly into a mutable bitmap% from >> racket/draw, or explore images/flomap. > > I haven’t looked at images/flomap yet, but it looks interesting. > >> Then there are the possibilities of Typed Racket optimizations, and >> profiling and the Optimization Coach in general. > > I didn’t want to try typed racket because 2htdp/image isn’t written in typed > racket, so there would be contract checks on every image function call. If I > have time to try images/flomap that won’t be a problem though. > I didn’t want to try profiling because in my experience it slows things way > down, and I don’t want to do that on code that already takes at least three > days to run. > I’ve already tried optimization coach on my code, but it didn’t have much > help to give. > > > On May 4, 2015, at 7:01 AM, Robby Findler wrote: > >> Just in case: freezing an image requires actually rendering it but >> constructing the image doesn't (it just builds a tree/dag matching fairly >> closely to the image operations you used). So the time for constructing the >> images can be pretty different than freezing them. >> >> Drawing a frozen image is a bitmap copy (and can be faster than rendering it >> if it is a complex image) so freezing the intermediate ones might help if >> intermediate ones are drawn many times. > > That’s why I started freezing these fractals. They were taking a long time to > draw in DrRacket, and then taking a long time to save as an image file on my > computer. So freezing them meant that it took a long time to freeze them, but > after that both drawing them in DrRacket and saving them to my computer were > quick. Plus I could use time to see how long it took to construct it versus > freeze it. > > The way I have it right now, I have a recursive function which uses a bunch > of calls to scene+line, so I do
Re: [racket-users] performance with freeze from 2htdp/image on very complex images
On May 4, 2015, at 12:49 AM, gfb wrote: > Those are beautiful. Thanks! > First, make sure in Choose Language / Show Details that it's set to "No > debugging or profiling", and that "Preserve stacktrace" not set. Already have that, but thanks for checking. > The 2htdp/image library has immutable images, so the image you're creating > contains all the line drawing "unexecuted" until you display or freeze it. > > There's a lot of symmetry, so rather than passing an image as a parameter can > you express the algorithm as returning one of the component images at each > level, then rotating and combining it with itself? As long as the result is > symmetric that will create a rather narrow Direct Acyclic Graph of images. I thought about doing that, and that’s what an example in the docs does, but I didn’t because I was afraid I would lose precision of exactly where the lines go, and since most of these fractals have multiple layers, that’s important. >From the example in the docs, at the smaller scales it doesn’t look sharp or >accurate to me, and would it really improve performance? Since they would be >all rotated from each other, I don’t think I would be able to reuse >computations very much. > You can then also experiment with freezing some of those intermediate images, > especially at the top levels where rotating a bitmap might be faster than > executing the drawing actions in a rotated co-ordinate system. But that's > speculation, not experience. The documentation for freeze says that freeze isn’t going to be helpful for images that will be scaled or rotated? If it were a serpinski carpet, I think this could probably help a lot, but for what I’m doing, I don’t think it would. > Other than that, consider drawing directly into a mutable bitmap% from > racket/draw, or explore images/flomap. I haven’t looked at images/flomap yet, but it looks interesting. > Then there are the possibilities of Typed Racket optimizations, and profiling > and the Optimization Coach in general. I didn’t want to try typed racket because 2htdp/image isn’t written in typed racket, so there would be contract checks on every image function call. If I have time to try images/flomap that won’t be a problem though. I didn’t want to try profiling because in my experience it slows things way down, and I don’t want to do that on code that already takes at least three days to run. I’ve already tried optimization coach on my code, but it didn’t have much help to give. On May 4, 2015, at 7:01 AM, Robby Findler wrote: > Just in case: freezing an image requires actually rendering it but > constructing the image doesn't (it just builds a tree/dag matching fairly > closely to the image operations you used). So the time for constructing the > images can be pretty different than freezing them. > > Drawing a frozen image is a bitmap copy (and can be faster than rendering it > if it is a complex image) so freezing the intermediate ones might help if > intermediate ones are drawn many times. That’s why I started freezing these fractals. They were taking a long time to draw in DrRacket, and then taking a long time to save as an image file on my computer. So freezing them meant that it took a long time to freeze them, but after that both drawing them in DrRacket and saving them to my computer were quick. Plus I could use time to see how long it took to construct it versus freeze it. The way I have it right now, I have a recursive function which uses a bunch of calls to scene+line, so I don’t have any points where there are intermediate images that are drawn many times that it would be helpful to freeze. I could restructure it to do that, but from the example in the docs, it looks like I’d loose sharpness, and the ability to control exactly where everything is, so that the things in all the different layers line up properly. -- 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
Just in case: freezing an image requires actually rendering it but constructing the image doesn't (it just builds a tree/dag matching fairly closely to the image operations you used). So the time for constructing the images can be pretty different than freezing them. Drawing a frozen image is a bitmap copy (and can be faster than rendering it if it is a complex image) so freezing the intermediate ones might help if intermediate ones are drawn many times. Robby On Sunday, May 3, 2015, Alexander D. Knauth wrote: > I’m trying to use 2htdp/image to generate images of fractals. > > But while generating the images is “relatively” quick, it is freezing the > images that’s taking a long time. > For the most complicated one, I started it running two nights ago, and the > freeze operation on it still hasn’t finished. > For the next worst one, it takes about 21 times longer to freeze it than > it takes to generate it. > > Why is it taking so long to freeze these images, and is there anything I > can do about it, like create the images in a certain way or give hints? > > The code that generates these fractals is here: > https://github.com/AlexKnauth/koch-snowflake > (and it is racket code, in case you’re wondering) > > For relatively small/simple fractals, freezing it takes anywhere from 1.5 > to 3.9 times longer than creating it. > For this one, freezing it takes a bit more than 3.5 times longer than > creating it. > time(img-expr): cpu time: 186 real time: 185 gc time: 26 > time(freeze(img)) : cpu time: 668 real time: 667 gc time: 31 > For this, about 3.9 times longer: > time(img-expr): cpu time: 141 real time: 141 gc time: 22 > time(freeze(img)) : cpu time: 549 real time: 549 gc time: 20 > > For a more complex fractal, about 21 times longer: > time(img-expr): cpu time: 18722 real time: 18807 gc time: 4304 > time(freeze(img)) : cpu time: 400357 real time: 405312 gc time: 214723 > And for this, about 18 times longer: > time(img-expr): cpu time: 8425 real time: 8547 gc time: 1203 > time(freeze(img)) : cpu time: 152594 real time: 153001 gc time: 64968 > And for this, about 17.8 times longer: > time(img-expr): cpu time: 27232 real time: 27264 gc time: 4254 > time(freeze(img)) : cpu time: 485319 real time: 504408 gc time: 210964 > > For the worst one: > time(img-expr): cpu time: 2177463 real time: 2455108 gc time: 1189933 > time(freeze(img)) : hasn’t finished yet > For this one, I started it two nights ago, and it’s still running. > > > -- > 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.
[racket-users] performance with freeze from 2htdp/image on very complex images
I’m trying to use 2htdp/image to generate images of fractals. But while generating the images is “relatively” quick, it is freezing the images that’s taking a long time. For the most complicated one, I started it running two nights ago, and the freeze operation on it still hasn’t finished. For the next worst one, it takes about 21 times longer to freeze it than it takes to generate it. Why is it taking so long to freeze these images, and is there anything I can do about it, like create the images in a certain way or give hints? The code that generates these fractals is here: https://github.com/AlexKnauth/koch-snowflake (and it is racket code, in case you’re wondering) For relatively small/simple fractals, freezing it takes anywhere from 1.5 to 3.9 times longer than creating it. For this one, freezing it takes a bit more than 3.5 times longer than creating it. time(img-expr): cpu time: 186 real time: 185 gc time: 26 time(freeze(img)) : cpu time: 668 real time: 667 gc time: 31 For this, about 3.9 times longer: time(img-expr): cpu time: 141 real time: 141 gc time: 22 time(freeze(img)) : cpu time: 549 real time: 549 gc time: 20 For a more complex fractal, about 21 times longer: time(img-expr): cpu time: 18722 real time: 18807 gc time: 4304 time(freeze(img)) : cpu time: 400357 real time: 405312 gc time: 214723 And for this, about 18 times longer: time(img-expr): cpu time: 8425 real time: 8547 gc time: 1203 time(freeze(img)) : cpu time: 152594 real time: 153001 gc time: 64968 And for this, about 17.8 times longer: time(img-expr): cpu time: 27232 real time: 27264 gc time: 4254 time(freeze(img)) : cpu time: 485319 real time: 504408 gc time: 210964 For the worst one: time(img-expr): cpu time: 2177463 real time: 2455108 gc time: 1189933 time(freeze(img)) : hasn’t finished yet For this one, I started it two nights ago, and it’s still running. -- 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.
