Repository : ssh://darcs.haskell.org//srv/darcs/packages/base On branch : master
http://hackage.haskell.org/trac/ghc/changeset/af5dc3f1d89859016a2e07b0b03516d55293af81 >--------------------------------------------------------------- commit af5dc3f1d89859016a2e07b0b03516d55293af81 Author: Simon Marlow <[email protected]> Date: Tue Jun 12 10:57:45 2012 +0100 add some UNPACKs to improve performance a bit >--------------------------------------------------------------- Control/Concurrent/Chan.hs | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/Control/Concurrent/Chan.hs b/Control/Concurrent/Chan.hs index 4bc72e3..be10c00 100644 --- a/Control/Concurrent/Chan.hs +++ b/Control/Concurrent/Chan.hs @@ -45,21 +45,26 @@ import Data.Typeable #include "Typeable.h" +#define _UPK_(x) {-# UNPACK #-} !(x) + -- A channel is represented by two @MVar@s keeping track of the two ends -- of the channel contents,i.e., the read- and write ends. Empty @MVar@s -- are used to handle consumers trying to read from an empty channel. -- |'Chan' is an abstract type representing an unbounded FIFO channel. data Chan a - = Chan (MVar (Stream a)) - (MVar (Stream a)) -- Invariant: the Stream a is always an empty MVar + = Chan _UPK_(MVar (Stream a)) + _UPK_(MVar (Stream a)) -- Invariant: the Stream a is always an empty MVar deriving Eq INSTANCE_TYPEABLE1(Chan,chanTc,"Chan") type Stream a = MVar (ChItem a) -data ChItem a = ChItem a (Stream a) +data ChItem a = ChItem a _UPK_(Stream a) + -- benchmarks show that unboxing the MVar here is worthwhile, because + -- although it leads to higher allocation, the channel data takes up + -- less space and is therefore quicker to GC. -- See the Concurrent Haskell paper for a diagram explaining the -- how the different channel operations proceed. _______________________________________________ Cvs-libraries mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-libraries
