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? On Sunday, April 4, 2021 at 7:11:02 PM UTC-5 Ryan Kramer wrote: > 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. > > On Sunday, April 4, 2021 at 12:55:32 PM UTC-5 Ryan Kramer wrote: > >> 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. >> > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/c4a87899-25c1-4095-b3d7-309007386ffen%40googlegroups.com.
