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 <alexan...@knauth.org> wrote: > > 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.
