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

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.
I had actually already tried also before posting, and this is why I used
these explicit `time` and `current-milliseconds` calls.

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.
No idea what these calls might be though.

I also tried on a different computer (older, but recent Mint), and it works
fine. Looks very local to my computer then.

Laurent

On Tue, Apr 22, 2014 at 1:41 PM, Robby Findler
<robby at eecs.northwestern.edu>wrote:

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140422/1c011628/attachment-0001.html>