I'm not sure if this will work, but here's an attempt to profile a 2htdp/universe program. If you put your program in one file called, say, tmp.rkt and then run the program below (closing the big-bang window after a while), you should get a profile of something. Maybe it will be useful.
#lang racket (require profile) (profile (dynamic-require "tmp.rkt" #f) #:threads #t) Robby On Tue, Apr 22, 2014 at 6:30 AM, Laurent <laurent.ors...@gmail.com> wrote: > Thank you all for your answers. The problem seems to be on my end then. > However, some other graphic programs that draw in a canvas are not slow on > my computer. > > Does `big-bang` do something in particular regarding graphics? > > Laurent > > > On Mon, Apr 21, 2014 at 10:29 PM, David Vanderson > <david.vander...@gmail.com> wrote: >> >> It's fast for me - Linux Mint, both Racket 6.0 and 6.0.1.5 (from git just >> now) with cairo 2.11200.2. >> >> Dave >> >> >> On 04/21/2014 11:10 AM, Laurent wrote: >> >> My version of Cairo is 2.11000.2. What's yours, Sean? >> (probably: ls /usr/lib/i386-linux-gnu/libcairo.so*) >> >> >> On Mon, Apr 21, 2014 at 4:51 PM, Robby Findler >> <ro...@eecs.northwestern.edu> wrote: >>> >>> If the versions of Cairo are the same, then that eliminates one >>> possible route of inquiry. >>> >>> Robby >>> >>> On Mon, Apr 21, 2014 at 9:45 AM, Laurent <laurent.ors...@gmail.com> >>> wrote: >>> > Thanks Sean. >>> > (I forgot to mention that I was testing on Racket 6.0.1.4). >>> > Apparently it does not lag on your machine, so it might be particular >>> > to my >>> > machine then? Strange. >>> > >>> > >>> > On Mon, Apr 21, 2014 at 4:32 PM, Sean Kanaley <skana...@gmail.com> >>> > wrote: >>> >> >>> >> Here's my log after pasting the source into command-line racket 6.0, >>> >> Ubuntu 12.04 32-bit: >>> >> >>> >> to-draw at 1649 >>> >> >>> >> to-draw: cpu time: 0 real time: 2 gc time: 0 >>> >> on-key a at 2934 >>> >> to-draw at 2934 >>> >> >>> >> to-draw: cpu time: 0 real time: 2 gc time: 0 >>> >> on-key s at 2970 >>> >> to-draw at 2970 >>> >> >>> >> to-draw: cpu time: 4 real time: 3 gc time: 0 >>> >> on-key d at 3044 >>> >> on-key f at 3044 >>> >> to-draw at 3045 >>> >> >>> >> to-draw: cpu time: 0 real time: 0 gc time: 0 >>> >> to-draw at 3069 >>> >> to-draw: cpu time: 0 real time: 1 gc time: 0 >>> >> on-key a at 3198 >>> >> on-key s at 3198 >>> >> to-draw at 3199 >>> >> >>> >> to-draw: cpu time: 4 real time: 3 gc time: 0 >>> >> to-draw at 3329 >>> >> >>> >> to-draw: cpu time: 4 real time: 1 gc time: 0 >>> >> to-draw at 3392 >>> >> to-draw: cpu time: 0 real time: 1 gc time: 0 >>> >> on-key g at 3430 >>> >> on-key j at 3430 >>> >> on-key k at 3430 >>> >> to-draw at 3430 >>> >> >>> >> to-draw: cpu time: 4 real time: 1 gc time: 0 >>> >> to-draw at 3467 >>> >> to-draw: cpu time: 0 real time: 1 gc time: 0 >>> >> on-key a at 3504 >>> >> on-key l at 3504 >>> >> to-draw at 3505 >>> >> >>> >> to-draw: cpu time: 0 real time: 1 gc time: 0 >>> >> to-draw at 3547 >>> >> >>> >> to-draw: cpu time: 4 real time: 1 gc time: 0 >>> >> to-draw at 3572 >>> >> to-draw: cpu time: 0 real time: 1 gc time: 0 >>> >> on-key h at 3602 >>> >> to-draw at 3602 >>> >> to-draw: cpu time: 0 real time: 1 gc time: 0 >>> >> on-key k at 3659 >>> >> on-key ; at 3659 >>> >> to-draw at 3659 >>> >> >>> >> to-draw: cpu time: 4 real time: 3 gc time: 0 >>> >> to-draw at 3689 >>> >> >>> >> to-draw: cpu time: 0 real time: 1 gc time: 0 >>> >> to-draw at 3725 >>> >> >>> >> to-draw: cpu time: 0 real time: 1 gc time: 0 >>> >> to-draw at 3776 >>> >> to-draw: cpu time: 0 real time: 1 gc time: 0 >>> >> >>> >> >>> >> >>> >> On Mon, Apr 21, 2014 at 10:00 AM, Laurent <laurent.ors...@gmail.com> >>> >> wrote: >>> >>> >>> >>> I have a 2htdp/universe program that used to run fast enough a few >>> >>> months >>> >>> ago, but now it is very slow and not usable. >>> >>> The slowness seems to be because of the on-screen rendering, and not >>> >>> because of the generation of the image. >>> >>> >>> >>> Here is a stripped-down version that shows this behavior: >>> >>> https://gist.github.com/Metaxal/11142941 >>> >>> >>> >>> In the following log, you see that the `on-key` events are very close >>> >>> one >>> >>> to the other (in milliseconds after the beginning of the program), >>> >>> but the >>> >>> corresponding `to-draw` events are separated by more than a second, >>> >>> even >>> >>> though generating the image (cpu time) takes almost no time: >>> >>> >>> >>> on-key a at 6906 >>> >>> on-key u at 6912 >>> >>> on-key i at 6912 >>> >>> on-key e at 6913 >>> >>> to-draw at 6913 >>> >>> to-draw: cpu time: 4 real time: 3 gc time: 0 >>> >>> to-draw at 8598 >>> >>> to-draw: cpu time: 4 real time: 2 gc time: 0 >>> >>> to-draw at 11948 >>> >>> to-draw: cpu time: 4 real time: 2 gc time: 0 >>> >>> to-draw at 13631 >>> >>> to-draw: cpu time: 0 real time: 2 gc time: 0 >>> >>> to-draw at 161839 >>> >>> to-draw: cpu time: 4 real time: 9 gc time: 0 >>> >>> >>> >>> During those long seconds, Xorg is almost at 100% cpu. >>> >>> >>> >>> However, using an empty scene instead of an image is fast. >>> >>> The time also depends on the size of the grid. >>> >>> >>> >>> I'm using Ubuntu 12.04 64bits. >>> >>> I have tried to replicate the behavior on older versions of racket >>> >>> (5.3.1 >>> >>> and 5.90.0.9) but it's the same. So maybe the problem is not on >>> >>> Racket's >>> >>> side but something has changed in Ubuntu? >>> >>> >>> >>> Does anyone else see the same behavior, either on the same platform >>> >>> or on >>> >>> a different one? >>> >>> >>> >>> Thanks, >>> >>> Laurent >>> >>> >>> >>> >>> >>> ____________________ >>> >>> Racket Users list: >>> >>> http://lists.racket-lang.org/users >>> >>> >>> >> >>> > >>> > >>> > ____________________ >>> > Racket Users list: >>> > http://lists.racket-lang.org/users >>> > >> >> >> >> >> ____________________ >> Racket Users list: >> http://lists.racket-lang.org/users >> >> > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users > ____________________ Racket Users list: http://lists.racket-lang.org/users
