<div dir="ltr"><div class="gmail_extra">No luck (empty profile). I also tried with errortrace and with providing/requiring main instead of dynamic-require and calling main in the profiling, but same effect. </div><div class="gmail_extra"> I had actually already tried also before posting, and this is why I used these explicit `time` and `current-milliseconds` calls. </div><div class="gmail_extra">I think the program itself is fast enough, but that it may make numerous X calls, that make Xorg use 100% cpu during those seconds. </div><div class="gmail_extra">No idea what these calls might be though. </div><div class="gmail_extra">I also tried on a different computer (older, but recent Mint), and it works fine. Looks very local to my computer then. </div><div class="gmail_extra"> </div><div class="gmail_extra">Laurent </div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Apr 22, 2014 at 1:41 PM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <div class="HOEnZb"><div class="h5"> On Tue, Apr 22, 2014 at 6:30 AM, Laurent <<a href="mailto:laurent.orseau@gmail.com">laurent.orseau@gmail.com</a>> 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 > <<a href="mailto:david.vanderson@gmail.com">david.vanderson@gmail.com</a>> 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 >> <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> 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 <<a href="mailto:laurent.orseau@gmail.com">laurent.orseau@gmail.com</a>> >>> 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 <<a href="mailto:skanaley@gmail.com">skanaley@gmail.com</a>> >>> > 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 <<a href="mailto:laurent.orseau@gmail.com">laurent.orseau@gmail.com</a>> >>> >> 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: >>> >>> <a href="https://gist.github.com/Metaxal/11142941" target="_blank">https://gist.github.com/Metaxal/11142941</a> >>> >>> >>> >>> 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: >>> >>> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> >>> >>> >>> >> >>> > >>> > >>> > ____________________ >>> > Racket Users list: >>> > <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> >>> > >> >> >> >> >> ____________________ >> Racket Users list: >> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> >> >> > > > ____________________ > Racket Users list: > <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> > </div></div></blockquote></div> </div></div>