Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#2891 closed bug (wontfix)

threadDelay appears to use excessive CPU in GHCi

Reported by: JeremyShaw Owned by:
Priority: normal Milestone:
Component: Compiler Version: 6.8.3
Keywords: Cc:
Operating System: Linux Architecture: x86
Type of failure: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

I have the following simple program:

import Control.Concurrent
main = threadDelay (106) >> main

If I run it in GHCi it requires 2-5% of my CPU. If i compile it, it
takes 0% of my CPU. It does not matter if I compile -O0, -O2,
-threaded, it always uses 0% (which is good).

I have only tested this under Linux (Ubuntu Hardy) and GHC 6.8.3 on one machine.

Change History (2)

comment:1 Changed 5 years ago by simonmar

  • Difficulty set to Unknown
  • Resolution set to wontfix
  • Status changed from new to closed

Ok, this program repeatedly waits for one second. When this is run with the threaded RTS, here's what happens:

  • the program calls threadDelay
  • 1/3 of a second later, the RTS notices that the program is idle and does a GC
  • after 1 second, the program wakes up again, etc.

so we get a full GC every second, which accounts for the 2% CPU usage: in GHCi there's about 5Mb of stuff in the heap when idle. You'll see the same effect when compiling the program with -threaded, but there the heap will be almost empty, so the GC won't take much time. Without -threaded there is no idle-time GC.

You can turn off the idle-time GC with the -I0 RTS option, e.g.

ghci +RTS -I0

The idle-time GC isn't there just for performance reasons, it's also for detecting deadlock. If the program has deadlocked, the only way to detect that (and send BlockedIndefinitely exceptions) is to do a GC, but we want to wait until the program looks idle before initiating the GC, hence the current behaviour.

comment:2 Changed 5 years ago by JeremyShaw

ok, I'll have to investigate more. Idle happstack applications under GHCi will sometimes use 20-50% of the CPU, but we don't seem to see the same issue when apps are compiled.

Note: See TracTickets for help on using tickets.