[racket] big-bang is slow to render on screen?

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.orseau at 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.vanderson at 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
>> <robby at 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.orseau at 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 <skanaley at 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.orseau at 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
>