- ghc-tickets - Haskell.org

[GHC] #8923: Add SmallArray# type
by GHC 29 Mar '14

29 Mar '14

#8923: Add SmallArray# type ------------------------------------+------------------------------------- Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Add a `SmallArray#` (and `SmallMutableArray#`) type that doesn't have a card table. This would * save some memory (two words per array), * make updates cheaper (no writing to the card table), and * make GC faster (no traversing the card table). The use case is the unordered-containers package, which uses small arrays to implement a hash array mapped trie. A starting point would be [changeset:0417404f5d1230c9d291ea9f73e2831121c8ec99/ghc], which added the card table to the current array type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 29 Mar '14

29 Mar '14

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by George): I can no longer reproduce this using 7.8rc2. I believe I am using a real gcc and perhaps was before. gcc --version gcc (GCC) 4.8.2 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. bash-3.2$ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/local/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.0.20140228") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.8.0.20140228") ,("Global Package DB","/usr/local/lib/ghc-7.8.0.20140228/package.conf.d") ] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8898: Overall improvement for randomIvalInteger
by GHC 28 Mar '14

28 Mar '14

#8898: Overall improvement for randomIvalInteger -------------------------------------+------------------------------------- Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Easy (less than 1 | at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: 5278 5280 1120 | -------------------------------------+------------------------------------- The current randomIvalInteger implementation uses repeated div operations to approximate the size of the desired random output, then generates that number of random values from the given RandomGen. It does not compensate for the "mod base" uniformity problem. It also assumes that all RandomGen implementations produce the same range of random values as StdGen. My new implementation addresses all these correctness issues, with potentially a slight performance improvement. Instead of performing repeated div base operations to determine the size of the desired range, this uses faster (* base) operations. An equivalent set of intermediate Integers is generated still. To compensate for the "`mod` base" uniformity problem, the desired range size is multiplied by the q factor (1000 in my code). When k is the desired range and b^(n) is the range of numbers generated, and d = b^(n) div k, some elements will have probability d/b^(n) and others will have probability (d+1)/b^(n), resulting in significant nonuniformity when d is very small. When you extend the generated range beyond the minimum by a factor of q, you are guaranteeed that d will be at least q, so the nonuniformity will be much less consequential. This implementation also works with any RandomGen, even ones that produce as little as a single bit of entropy per next call or have a minimum bound other than zero. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8898> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8934: Advice To Help You Lose Weight ORIGINAL GARCINIA CAMBOGIA
by GHC 28 Mar '14

28 Mar '14

#8934: Advice To Help You Lose Weight ORIGINAL GARCINIA CAMBOGIA ------------------------------------+------------------------------------- Reporter: governer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As slim and skinny became the opening faith during this reproduction, unit reduction product has gained rank quality. The marketplace has been booming of these sorts of product. To exact some, these conservative valuate tea, slimming irregular, slimming pills, slimming belts, butterflies and lots of others. It is proliferated to a large difference that it is usually troublesome to request unconnected that among the different angulate measures rattling hearty and impressive. A word on a come of the fluid same tea and pills are tackled on this book to assistance yo [http://originalgarciniacambogiaresults.com/ ORIGINAL GARCINIA CAMBOGIA] u opt for that to use. Turn 24 Pro There conservative express numerous articles that assure tea as a acceptable slimming broker. Fit, there\'s any emancipationist to that still tea solitary cannot fulfil. Erst you eat in repast or alimentation second a day, you\'ll be fit to really retrogress cardinal to eighty calories on a daily cornerstone. This can be done thanks to the method of thermogenesis, a method of hotness production in organisms equivalent humans. With this, your metabolism can amount siamese to still exertion module increase our metastasis. With inflated metabolism, you\'ll be willing to contract the content that you rightful decrease a quicker peak of a discount of phoebe century to one grand calories on a daily foundation so as to advise that one to 2 blow weight exit. Tea cannot full vibration that. If that is the person then you bed got to eat the peak days as tercet month on a daily part. Thence, tea gift solely use as an Link in Nursing help. Fasting and workout conservativist amount plant more unimaginative than but uptake small 24 pro. Slimm 24 Pro Working Slimm 24 Pro fluid guarantees to mend out its personalty in a real victimize assets of your dimension. Siamese to the different consume, slimming powder should be punctually formal by a pupil. They're honest value reasons behindhand this. For one, slimming set number step ideally formal if and as extended as diet and apply tract instrument well-tried to be useless. Other instance, pills entails risks and complications. Connatural to the separate chemical devoured value accountable when making a selection what to gazump up and what ought to be excreted within the embody. Since these tablets or capsules aren\'t just confiscate on one part solely object for a become of your term (sometimes modify dual doses a day), it carries the danger of morbidity. Formerly our embody is overfull of toxins, it damages our great meat specially the liver and kidneys. These 2 parcel assess unexpendable that is why we change to tell superior reparation of them. http://originalgarciniacambogiaresults.com/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8934> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7644: Hackage docs for base library contain broken links
by GHC 28 Mar '14

28 Mar '14

#7644: Hackage docs for base library contain broken links -------------------------------------+------------------------------------ Reporter: JulesBean | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * owner: => hvr Comment: I'll pay attention to this when generating & uploading the docs to Hackage for [hackage:base] et al. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7644#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6056: INLINABLE pragma prevents worker-wrapper to happen.
by GHC 27 Mar '14

27 Mar '14

#6056: INLINABLE pragma prevents worker-wrapper to happen. --------------------------------------------+------------------------------ Reporter: milan | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): I tested this just now on current HEAD (well, built 2 weeks ago) here are the three versions {{{ module Test where smallerAndRest :: Ord a => a -> [a] -> (Maybe a, [a]) smallerAndRest x [] = (Nothing, []) smallerAndRest x (y:ys) | y < x = (Just y, ys) | otherwise = smallerAndRest x ys {-# INLINABLE smallerAndRest #-} smallerAndRestGood :: Ord a => a -> [a] -> (Maybe a, [a]) smallerAndRestGood x ys = go x ys where go x [] = (Nothing, []) go x (y:ys) | y < x = (Just y, ys) | otherwise = go x ys {-# INLINABLE smallerAndRestGood #-} smallerAndRestGoodNotInlined :: Ord a => a -> [a] -> (Maybe a, [a]) smallerAndRestGoodNotInlined x ys = go x ys where go x [] = (Nothing, []) go x (y:ys) | y < x = (Just y, ys) | otherwise = go x ys }}} i used {{{ ghc -O1 -ddump-prep test.hs -fforce-recomp }}} with the following results {{{ ==================== CorePrep ==================== Result size of CorePrep = {terms: 123, types: 192, coercions: 0} lvl_r10X :: forall a_aTr. (Data.Maybe.Maybe a_aTr, [a_aTr]) [GblId, Caf=NoCafRefs, Str=DmdType m, Unf=OtherCon []] lvl_r10X = \ (@ a_aTr) -> (Data.Maybe.Nothing @ a_aTr, GHC.Types.[] @ a_aTr) Rec { Test.smallerAndRest [InlPrag=INLINABLE[ALWAYS], Occ=LoopBreaker] :: forall a_aDK. GHC.Classes.Ord a_aDK => a_aDK -> [a_aDK] -> (Data.Maybe.Maybe a_aDK, [a_aDK]) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <L,U(A,A,C(C1(U)),A,A,A,A,A)><L,U><S,1*U>m, Unf=OtherCon []] Test.smallerAndRest = \ (@ a_aTr) ($dOrd_s17b :: GHC.Classes.Ord a_aTr) (x_s17c :: a_aTr) (ds_s17d [Occ=Once!] :: [a_aTr]) -> case ds_s17d of _ [Occ=Dead] { [] -> lvl_r10X @ a_aTr; : y_s17f ys_s17g [Occ=Once*] -> case GHC.Classes.< @ a_aTr $dOrd_s17b y_s17f x_s17c of _ [Occ=Dead] { GHC.Types.False -> Test.smallerAndRest @ a_aTr $dOrd_s17b x_s17c ys_s17g; GHC.Types.True -> let { sat_s17i [Occ=Once] :: Data.Maybe.Maybe a_aTr [LclId, Str=DmdType] sat_s17i = Data.Maybe.Just @ a_aTr y_s17f } in (sat_s17i, ys_s17g) } } end Rec } Test.smallerAndRestGood [InlPrag=INLINABLE[ALWAYS]] :: forall a_aDJ. GHC.Classes.Ord a_aDJ => a_aDJ -> [a_aDJ] -> (Data.Maybe.Maybe a_aDJ, [a_aDJ]) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <L,U(A,A,C(C1(U)),A,A,A,A,A)><L,U><S,1*U>m, Unf=OtherCon []] Test.smallerAndRestGood = \ (@ a_aTb) ($dOrd_s17j :: GHC.Classes.Ord a_aTb) (x_s17k [Occ=Once] :: a_aTb) (ys_s17l [Occ=Once] :: [a_aTb]) -> let { lvl1_s17m [Occ=OnceL!] :: a_aTb -> a_aTb -> GHC.Types.Bool [LclId, Str=DmdType] lvl1_s17m = GHC.Classes.< @ a_aTb $dOrd_s17j } in letrec { $wgo_s17n [Occ=LoopBreaker] :: a_aTb -> [a_aTb] -> (# Data.Maybe.Maybe a_aTb, [a_aTb] #) [LclId, Arity=2, Str=DmdType <L,U><S,1*U>, Unf=OtherCon []] $wgo_s17n = \ (w_s17o :: a_aTb) (w1_s17p [Occ=Once!] :: [a_aTb]) -> case w1_s17p of _ [Occ=Dead] { [] -> (# Data.Maybe.Nothing @ a_aTb, GHC.Types.[] @ a_aTb #); : y_s17r ys1_s17s [Occ=Once*] -> case lvl1_s17m y_s17r w_s17o of _ [Occ=Dead] { GHC.Types.False -> $wgo_s17n w_s17o ys1_s17s; GHC.Types.True -> let { sat_s17u [Occ=Once] :: Data.Maybe.Maybe a_aTb [LclId, Str=DmdType] sat_s17u = Data.Maybe.Just @ a_aTb y_s17r } in (# sat_s17u, ys1_s17s #) } }; } in case $wgo_s17n x_s17k ys_s17l of _ [Occ=Dead] { (# ww1_s17w [Occ=Once], ww2_s17x [Occ=Once] #) -> (ww1_s17w, ww2_s17x) } Test.$wsmallerAndRestGoodNotInlined :: forall a_aql. GHC.Classes.Ord a_aql => a_aql -> [a_aql] -> (# Data.Maybe.Maybe a_aql, [a_aql] #) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <L,U(A,A,C(C1(U)),A,A,A,A,A)><L,U><S,1*U>, Unf=OtherCon []] Test.$wsmallerAndRestGoodNotInlined = \ (@ a_aql) (w_s17y :: GHC.Classes.Ord a_aql) (w1_s17z [Occ=Once] :: a_aql) (w2_s17A [Occ=Once] :: [a_aql]) -> let { lvl1_s17B [Occ=OnceL!] :: a_aql -> a_aql -> GHC.Types.Bool [LclId, Str=DmdType] lvl1_s17B = GHC.Classes.< @ a_aql w_s17y } in letrec { $wgo_s17C [Occ=LoopBreaker] :: a_aql -> [a_aql] -> (# Data.Maybe.Maybe a_aql, [a_aql] #) [LclId, Arity=2, Str=DmdType <L,U><S,1*U>, Unf=OtherCon []] $wgo_s17C = \ (w3_s17D :: a_aql) (w4_s17E [Occ=Once!] :: [a_aql]) -> case w4_s17E of _ [Occ=Dead] { [] -> (# Data.Maybe.Nothing @ a_aql, GHC.Types.[] @ a_aql #); : y_s17G ys_s17H [Occ=Once*] -> case lvl1_s17B y_s17G w3_s17D of _ [Occ=Dead] { GHC.Types.False -> $wgo_s17C w3_s17D ys_s17H; GHC.Types.True -> let { sat_s17J [Occ=Once] :: Data.Maybe.Maybe a_aql [LclId, Str=DmdType] sat_s17J = Data.Maybe.Just @ a_aql y_s17G } in (# sat_s17J, ys_s17H #) } }; } in $wgo_s17C w1_s17z w2_s17A Test.smallerAndRestGoodNotInlined [InlPrag=INLINE[0]] :: forall a_aql. GHC.Classes.Ord a_aql => a_aql -> [a_aql] -> (Data.Maybe.Maybe a_aql, [a_aql]) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <L,U(A,A,C(C1(U)),A,A,A,A,A)><L,U><S,1*U>m, Unf=OtherCon []] Test.smallerAndRestGoodNotInlined = \ (@ a_aql) (w_s17K [Occ=Once] :: GHC.Classes.Ord a_aql) (w1_s17L [Occ=Once] :: a_aql) (w2_s17M [Occ=Once] :: [a_aql]) -> case Test.$wsmallerAndRestGoodNotInlined @ a_aql w_s17K w1_s17L w2_s17M of _ [Occ=Dead] { (# ww1_s17O [Occ=Once], ww2_s17P [Occ=Once] #) -> (ww1_s17O, ww2_s17P) } }}} this seems to hint that doing worker wrapper by hand works, whether or not you marked it INLINEABLE. (i don't know enough about this topic to judge if that means its resolved or still a problem mind you) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6056#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6017: Reading ./.ghci files raises security issues
by GHC 27 Mar '14

27 Mar '14

#6017: Reading ./.ghci files raises security issues -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Marlow <marlowsd@…>): In [changeset:"a6f2c852d49313fa8acea2deb3741ab86c6ef995/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a6f2c852d49313fa8acea2deb3741ab86c6ef995" Don't perform permission checks for scripts named with -ghci-script (#6017) The user explicitly requested this script on the command-line, so it's unnecessary to require that the script is also owned by the user. Also, it is currently impossible to make a GHCi wrapper that invokes a custom script without first making a copy of the script to circumvent the permissions check, which seems wrong. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6017#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #989: Windows "native" port
by GHC 27 Mar '14

27 Mar '14

#989: Windows "native" port ---------------------------------+---------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Difficult (2-5 days) Test Case: N/A | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------------- Comment (by schyler): Just thought I would make a note that this is kind of blocking visual studio support. It's not easy to make a uniform visual studio extension for Haskell right now because it would be expected that it's able to link with other files in the same solution (.c, .cpp etc) however that's not the case since GHC uses gcc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/989#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8930: GHC API: List of available Pragmas
by GHC 27 Mar '14

27 Mar '14

#8930: GHC API: List of available Pragmas ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- From https://github.com/kazu-yamamoto/ghc- mod/issues/103#issuecomment-14827257: It would be useful if the GHC API allowed us to query a list of supported pragmas. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8930> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8900: unordered-containers 19% slower in HEAD vs 7.6.3
by GHC 25 Mar '14

25 Mar '14

#8900: unordered-containers 19% slower in HEAD vs 7.6.3 ------------------------------+-------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Runtime performance bug (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I ran a simple benchmark that exercises `Data.HashMap.Lazy.insert`. It's 19% slower using HEAD compared to using 7.6.3. The generated Core is the same, but the new codegen generates substantially different Cmm. '''Steps to reproduce''' 1. Download the attached `HashMapInsert.hs` benchmark. 2. Install unordered-containers with both 7.6.3 and HEAD: {{{ $ cabal install -w ghc-7.6.3 unordered-containers-0.2.3.3 $ cabal install -w inplace/bin/ghc-stage2 unordered-containers-0.2.3.3 }}} 3. Compile the benchmark with both compilers: {{{ $ ghc-7.6.3 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertOld $ inplace/bin/ghc-stage2 -O2 HashMapInsert.hs $ mv HashMapInsert HashMapInsertNew }}} '''Results (best of 3 runs)''' 7.6.3 {{{ $ ./HashMapInsertOld +RTS -s 1,191,223,528 bytes allocated in the heap 141,978,520 bytes copied during GC 37,811,840 bytes maximum residency (8 sample(s)) 22,378,432 bytes maximum slop 99 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2277 colls, 0 par 0.06s 0.06s 0.0000s 0.0002s Gen 1 8 colls, 0 par 0.07s 0.10s 0.0127s 0.0479s INIT time 0.00s ( 0.00s elapsed) MUT time 0.24s ( 0.24s elapsed) GC time 0.13s ( 0.17s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.37s ( 0.41s elapsed) %GC time 34.8% (40.3% elapsed) Alloc rate 4,923,204,681 bytes per MUT second Productivity 65.2% of total user, 59.0% of total elapsed }}} HEAD: {{{ $ ./HashMapInsertNew +RTS -s 1,191,223,128 bytes allocated in the heap 231,158,688 bytes copied during GC 55,533,064 bytes maximum residency (13 sample(s)) 22,378,488 bytes maximum slop 144 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2268 colls, 0 par 0.06s 0.07s 0.0000s 0.0003s Gen 1 13 colls, 0 par 0.12s 0.16s 0.0127s 0.0468s INIT time 0.00s ( 0.00s elapsed) MUT time 0.25s ( 0.25s elapsed) GC time 0.18s ( 0.23s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 0.43s ( 0.49s elapsed) %GC time 41.6% (47.5% elapsed) Alloc rate 4,738,791,249 bytes per MUT second Productivity 58.3% of total user, 51.9% of total elapsed }}} (Note that this is without the patches in #8885, so they're not the cause.) An interesting difference is that we spend more time in GC in HEAD. I don't know if that's related. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8900> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25