I ran the program with your modifications, but counter to the documentation <https://docs.racket-lang.org/gui/event_.html?q=get-time-stamp#%28meth._%28%28%28lib._mred%2Fmain..rkt%29._event~25%29._get-time-stamp%29%29>, the values I get from get-time-stamp don't seem at all similar to current-milliseconds or current-inexact-milliseconds. I ended up defining delta as follows (with 1559695139340 being a guess):
(define delta (- (current-inexact-milliseconds) 1559695139340 (send event get-time-stamp))) Here are the results: $ ./racket-7.2/bin/racket ~/Code/racket/chart-lag-test.rkt Mouse Min: 2.425048828125 Max: 97.818115234375 Mean: 30.901338585251057 StdDev: 28.349128820378922 Paint Min: 0.282958984375 Max: 10.380859375 Mean: 4.27886962890625 StdDev: 4.162199753791872 $ ./racket-7.3.0.4/bin/racket ~/Code/racket/chart-lag-test.rkt Mouse Min: 2.034912109375 Max: 295.45703125 Mean: 54.28094064372857 StdDev: 40.51587689852278 Paint Min: 0.177978515625 Max: 6.715087890625 Mean: 3.2418212890625 StdDev: 2.868002614564615 So this perhaps shows that mouse events are being triggered almost twice as slowly in 7.3, but I think my hack makes these numbers unreliable. Also, the latency experienced interacting with the plot seems much worse than just twice as slow. Are you at least able to see a disconnect between current-inexact-milliseconds and get-time-stamp? Evan On Wednesday, June 5, 2019 at 2:17:46 AM UTC-10, Alex Harsanyi wrote: > > I had a look at the code and it is not exactly what I had in mind for the > measurements. The problem with your measurements is that the canvas is > re-drawn only when needed, so the time between two calls to on-paint is not > relevant for performance measurements. > > For the on-paint, the time of the draw itself needs to be measured: > > (define/override (on-paint) > (define begin-timestamp (current-inexact-milliseconds)) > (super on-paint) > (define end-timestamp (current-inexact-milliseconds)) > (set! paint-event-stats > (update-statistics paint-event-stats (- end-timestamp begin- > timestamp)))) > > For the mouse event, the time between when the event is created and the > time it is passed to the callback: > > (define ((make-current-value-renderer fn) snip event x y) > (define delta (- (current-inexact-milliseconds) (send event get-time- > stamp))) > (set! mouse-event-stats (update-statistics mouse-event-stats delta)) > (define overlays > (and x y (eq? (send event get-event-type) 'motion) > (list (vrule x #:style 'long-dash) > (point-label (vector x (fn x)) #:anchor 'auto)))) > (send snip set-overlay-renderers overlays)) > > > Alex. > > On Wednesday, June 5, 2019 at 8:06:26 PM UTC+8, evdubs wrote: >> >> Thanks for responding, Alex. >> >> Here's what I came up with <http://pasterack.org/pastes/893> that I >> think satisfies your recommendations. It shows the sin() plot, expects >> interaction for 10 seconds, then prints min/max/mean/std dev for both the >> mouse-event-callback for the snip and on-paint for the editor-canvas%. >> >> Here's the output from running that with Racket 7.2 and Racket 7.3.0.4: >> >> $ ./racket-7.2/bin/racket ~/Code/racket/chart-lag-test.rkt >> Mouse >> Min: 1.115966796875 >> Max: 1209.123046875 >> Mean: 40.23961775104986 >> StdDev: 81.88591520019294 >> >> Paint >> Min: 3.35302734375 >> Max: 275.579833984375 >> Mean: 79.6534423828125 >> StdDev: 113.45367443728956 >> >> $ ./racket-7.3.0.4/bin/racket ~/Code/racket/chart-lag-test.rkt >> Mouse >> Min: 1.072021484375 >> Max: 1095.2412109375 >> Mean: 21.93592705160883 >> StdDev: 54.53777963909044 >> >> Paint >> Min: 3.18798828125 >> Max: 284.447998046875 >> Mean: 80.8831787109375 >> StdDev: 117.90272049413493 >> >> These numbers seem to suggest that 7.3 is an improvement, at least from >> the mouse-event stats, even though that is counter to the experience from >> interacting with the plot. Have any other ideas? >> >> Evan >> >> On Tuesday, June 4, 2019 at 1:39:49 PM UTC-10, Alex Harsanyi wrote: >>> >>> >>> >>> On Tuesday, June 4, 2019 at 11:32:42 AM UTC+8, evdubs wrote: >>>> >>>> Thanks for trying it out. >>>> >>>> I just tried using the bash installer from >>>> https://download.racket-lang.org/ and I experience the same issue of >>>> lagginess in 7.3. I also tried using a snapshot release from >>>> https://plt.eecs.northwestern.edu/snapshots/ and I experienced the >>>> same issue. >>>> >>>> I am not sure what I should try next other than maybe profiling, but I >>>> have not had much luck making effective use of the profiler in the past >>>> for >>>> interactive applications. >>>> >>> >>> Here are a few things you can try: >>> >>> First, check again whether there’s a performance drop in Racket 7.2 too >>> -- you >>> don’t want to spend time tracking down a Racket problem only to find out >>> that >>> the latest Ubuntu update disabled the hardware acceleration on the >>> graphics >>> card. >>> >>> If it is indeed a regression in Racket 7.3, you can try narrowing the >>> problem >>> down to either rendering or mouse event delays: >>> >>> * you can measure the time it takes to render the plot by measuring the >>> time >>> the paint method of the `editor-canvas%`. You will need to create a >>> custom >>> `editor-canvas%` and override `on-paint` and use >>> `current-inexact-milliseconds` to measure the time. >>> >>> * to check if mouse events are delivered too late to the callback. You >>> can use >>> the `get-time-stamp` method on the event and compare it against >>> `current-inexact-milliseconds` to determine the delay. >>> >>> You will need to compare both values against Racket 7.2 to see which one >>> is >>> causing the slow down. >>> >>> Alex. >>> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/0c0648e2-7013-4422-825f-25235e6618c9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
