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
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
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 72
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 ou
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 suggest
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
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, wi
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 immut
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 bi
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
10 matches
Mail list logo
