Ticket #2 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

Possible optimization: using select for detecting input instead of non-block reads w/ threadDelay

Reported by: coconnor Owned by: coconnor
Priority: major Milestone:
Component: Uncategorized Version:
Keywords: Cc:

Description

The CPU usage of programs using VTY is higher that expected. Experimenting with the input handling thread indicates that how input is handled is the primary bottleneck.

  1. Verify input handling is bottleneck
  2. Try using select in the same manner as VIM.

Change History

Changed 6 years ago by judah

Just a suggestion: have you tried using Control.Concurrent.threadWaitRead? I've found it to be pretty useful and the idle CPU usage is very little (I think it calls select under the hood).

You may also be interested in the comments in the following task:

http://hackage.haskell.org/trac/ghc/ticket/2363

Or check out the program (not yet well-commented, unfortunately) that I'm working on where I use it (look for the functions getEvent and readKeyEvents):

http://code.haskell.org/haskeline/System/Console/Haskeline/Backend/Posix.hsc

Changed 6 years ago by coconnor

  • component changed from component1 to Uncategorized

Changed 6 years ago by coconnor

Pushed patch that changed input handling to use Control.Concurrent.threadWaitRead. This improved the situation with regard to issue #6 as well. Will resolve as fixed once the patch is verified to not cause any regressions.

Changed 6 years ago by coconnor

  • status changed from new to assigned

idle CPU usage of yi not using threadWaitRead on a Core 2 Duo 2ghz MacBook? Pro: 0.8 idle CPU usage of yi using threadWaitRead on a Core 2 Duo 2ghz MacBook? Pro: 0.0

Changed 6 years ago by coconnor

  • status changed from assigned to closed
  • resolution set to fixed

Looks good. Closing as fixed.

Note: See TracTickets for help on using tickets.