search

hvr / ThreadScope

Official upstream repo for ThreadScope (issue tracker still using trac)
http://trac.haskell.org/ThreadScope
Other
0 stars 0 forks source link

Lag when loading an eventlog, if no mouse activity over the TS window #23

Closed ghc-mirror closed 10 years ago

ghc-mirror commented 10 years ago

Original reporter: MikolajKonarski

Quite often there is a lag of a few seconds when an eventlog loads. It may not be just speed of analyzing the new events, however, because clicking on the TS window seems to speed it up. It's also not consistent.

Some more tests:

Disabling the progress window and the forced evaluation of data does not affect the lag.

The lag is the same when loading an eventlog as when starting with an eventlog from the command line.

Moving the mouse in the TS window speeds things up. Keeping the mouse outside the TS window delays drawing forever (most of the time). More specifically, moving the mouse over any graphical element drawn by us cancels the lag, while moving it over text areas or even switching tabs in the lower pane does not end the lag (most of the time).

The problem is much less pronounced, but still there in 0.2.1, and as pronounced as currently in 0.2.0, both compiled with the newest ghc-events and libs. So it looks like a problem not in TS.

Edit: tested with TS 0.2.0 and ghc-events 0.3.0.1 and the lag persists. I have a hunch -threaded could help, but no idea why there's a problem. Nobody reported a similar problem so far, so it may be specific to 7.4.1 or the newest gtk2hs or my gtk version, too.

ghc-mirror commented 10 years ago

Original reporter: MikolajKonarski

Fixed. This is a part of the story:

13:25 <@dcoutts> mikolaj: see GUI/Main.hs,  ConcurrencyControl.fullSpeed concCtl $ ...
13:26 <@dcoutts> mikolaj: re the scheduling thing, because we're using cooperative scheduling with gtk, we only run Haskell threads on a timer
13:26 <@dcoutts> mikolaj: which is ok when we're idle, but when we're doing cpu bound things, we need to run whenever gtk is idle
13:27 <@dcoutts> so you see in loadEvents we use the ConcurrencyControl.fullSpeed
13:27 <@dcoutts> sounds like we should do the same for recalculating things in the other view
13:27 <@mikolaj> oh, ok, I will experiment over the weekend

Another part is that the hack partially working around #1 adds an extra delay during which the user can move the mouse away from the window and cause the lag. Both the fullSpeed tweak and disabling the hack were required to fix the issue.

ghc-mirror commented 10 years ago

Original reporter: MikolajKonarski

Some more info in case we ever revisit the issue:

16:30 <@dcoutts> mikolaj: that's very odd, can to add tracing to the ConcurrencyControl to see if the gtk idle or timer is still firing?
17:52 <@mikolaj> dcoutts: I can't reproduce the bug with the hacky delay reenabled plus the trace printouts (without printouts I get it about 1 in 50 times; here I tried, say 200 times)
17:52 <@mikolaj> dcoutts:I also can't reproduce the bug with the hacky delay disabled, after about 200 tries --- draw your own conclusions, it's not a proof of anything, obviously
17:52 <@mikolaj> dcoutts:the traces I've added are like this: Glib.timeoutAddFull (trace "timeoutAddFull" Concurrent.yield >> return True)
so, with the whole bugfix disabled, I get the bug 1 in 2 times and first the idleAdd is fired repeatedly, when the progress bar is shown
17:52 <@mikolaj> dcoutts:and then the progress bar vanishes and the window freezes and timeoutAddFull is fired repeatedly
17:52 <@mikolaj> dcoutts:and when I move the mouse over the window, it's redrawn, but there is no change with the printouts: timeoutAddFull is printed repeatedly as before