How do I debug this performance problem?

[Ryan Kramer]

I am working on prototyping a video game. I have a function `state->pict` that takes a game state and creates a pict to be drawn on a canvas. When I `time` this function I get nice low numbers like "cpu time: 0 real time: 2 gc time: 0"

The problem occurs when I am running a networked multiplayer game. The size and complexity of the state remains the same (a "state" represents only one player's state). But the mere presence of other threads doing network IO somehow slows down `state->pict` which is strange because it is a pure function. I get timing results like "cpu time: 78 real time: 71 gc time: 0". If I stop the network activity mid-game, after a few seconds it will start running quickly again.

This makes me think that other threads are interrupting state->pict and that this interruption is being captured by `time`. Is that plausible?

Do I need to use a separate place for the network request/response queue? Right now, I am just using `thread` like this:

    ; (-> request (evtof response))
    (define/public (sendrq rq)
      (let ([result (box #f)])
        (wrap-evt (thread (lambda () (set-box! result (send/recv rq))))
                  (lambda args (unbox result)))))

There is one other area that concerns me: I am using `read` on the input-port returned by `tcp-connect`. I was hoping that `read` would yield while it is waiting for the datum to arrive on the port, but maybe it spins instead which would explain the elevated CPU usage.

I tried `raco profile my-game.rkt` but that only profiles the time it takes to show the initial frame. Is there some other technique I can use to profile the game while it is running?

Thanks in advance for any suggestions.

[Ryan Kramer]

I either forgot or never learned that the profile functionality is available programmatically. And `create-sampler` can track a single thread which is exactly what I want (the UI thread). The profile results are surprising, but at least I have some ideas to try now.

[Ryan Kramer]

It turns out that a chaperone introduced at the typed-untyped boundary was causing a certain important function to run at least 20x slower. I've added prop:authentic to all my structs and am updating the code so that Typed Racket no longer tries to create chaperones.

I've noticed that Typed Racket adds seemingly unnecessary chaperones when the Any type is involved, but maybe they are necessary for some reason? The following code tries to create a chaperone that I don't think is necessary.

#lang racket

(module m typed/racket
  (provide f)
  (: f (-> Any Any))
  (define (f x) x))
(require 'm)

(struct s (a b) #:transparent #:authentic)
(f (s 1 2))

Is there a reason for the chaperone? Should I report this and similar situations as Github issues?

[Ben Greenman]

> I've noticed that Typed Racket adds seemingly unnecessary chaperones when
> the Any type is involved, but maybe they are necessary for some reason? The
> following code tries to create a chaperone that I don't think is necessary.
>
> #lang racket
>
> (module m typed/racket
> (provide f)
> (: f (-> Any Any))
> (define (f x) x))
> (require 'm)
>
> (struct s (a b) #:transparent #:authentic)
> (f (s 1 2))
>
> Is there a reason for the chaperone? Should I report this and similar
> situations as Github issues?

Typed Racket uses Any chaperones to protect its values from untyped
code. For example, if typed code sent a vector to untyped, then the
Any chaperone would prevent `vector-set!`s

I agree the chaperone isn't necessary in your example because `f`
never receives a typed value. I also can't think of a way to use an
un-chaperoned version of `f` to break type soundness ... so maybe
there is a general principle here, about how a typed function creates
an Any result, that TR could learn.

If you have ideas and/or more examples, then yes please open an issue.